Re: org-cite-list-bibliography-files
On 2021-07-28 Wed 15:12, Bruce D'Arcus wrote: > Titus' second question got lost a bit, but does anyone have an answer? > > I have the same issue, but was thinking clicking should run org-open-at-point. To avoid misunderstandings, I agree that a mouse click should run org-open-at-point. However, for C-c C-c it it would perhaps be more useful if it would run org-cite-insert. (On ordinary org links C-c C-c doesn’t appear to do anything.) Titus > > I know some other people do get clickable links, so am wondering if > it's a config issue? > > On Sun, Jul 25, 2021 at 10:47 AM Titus von der Malsburg > wrote: > >> 2. The oc-basic processor makes citations look like clickable links (blue, >> underlined, mouse pointer changes to finger), but when I click on them, >> nothing happens. I can only follow a references via `org-open-at-point'. >> It would be good to make citations clickable. I also suggest allowing users >> to follow links via C-c C-c which currently doesn’t do anything on >> citations. The other obvious action that C-c C-c could trigger would be >> `org-cite-insert'. Not sure what’s better.
Re: org-cite-list-bibliography-files
On 2021-07-25 Sun 17:14, Bruce D'Arcus wrote: > On Sun, Jul 25, 2021 at 10:47 AM Titus von der Malsburg > wrote: >> >> >> Hi, >> >> I’m starting to learn about org’s new capabilities for citations and >> bibliographies. Exciting, and great work! >> >> Two suggestions/requests: >> >> 1. `org-cite-list-bibliography-files' returns the bibliographies defined >> locally and the globally defined bibliographies together. I propose to only >> list the local bibliographies, if defined, and to return the global >> bibliographies otherwise. I think the user needs a way to override the >> global setting if necessary. For example, when I work on a manuscript, I’d >> like to use that manuscript’s dedicated bibliography, but ignore my global >> bibliography. It’s very common to work with dedicated bibliographies IME, >> and the UI of oc-basic doesn’t show from which bibliography an entry is >> coming. So there’s no way to reliably select entries from just the >> dedicated/local bibliography. > > There was a thread here last week on this, and we realized that one > can already override this behavior. > > https://lists.gnu.org/archive/html/emacs-orgmode/2021-07/msg00499.html > > # Local Variables: > # org-cite-global-bibliography: nil > # End: Sure, that’s always possible. However, my suspicion is that users in the majority of cases want /just/ the local bibliography when they specify one. If true, a better default would be to only return the local bibliography. Personally, I can’t think of a use case where you would like to use a mix of multiple bibliographies, local and global, especially where there is no way to see from which bibliography each entry is coming. What about duplicates, for instance, i.e. entries that exist in multiple bibliographies? Titus
org-cite-list-bibliography-files
Hi, I’m starting to learn about org’s new capabilities for citations and bibliographies. Exciting, and great work! Two suggestions/requests: 1. `org-cite-list-bibliography-files' returns the bibliographies defined locally and the globally defined bibliographies together. I propose to only list the local bibliographies, if defined, and to return the global bibliographies otherwise. I think the user needs a way to override the global setting if necessary. For example, when I work on a manuscript, I’d like to use that manuscript’s dedicated bibliography, but ignore my global bibliography. It’s very common to work with dedicated bibliographies IME, and the UI of oc-basic doesn’t show from which bibliography an entry is coming. So there’s no way to reliably select entries from just the dedicated/local bibliography. 2. The oc-basic processor makes citations look like clickable links (blue, underlined, mouse pointer changes to finger), but when I click on them, nothing happens. I can only follow a references via `org-open-at-point'. It would be good to make citations clickable. I also suggest allowing users to follow links via C-c C-c which currently doesn’t do anything on citations. The other obvious action that C-c C-c could trigger would be `org-cite-insert'. Not sure what’s better. Titus
Re: CSL-JSON support for =parsebib=
On 2021-05-07 Fri 16:47, Joost Kremers wrote:
> 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.
I agree that weird characters are unlikely going to be an issue. Nonetheless,
strings seem slightly more future-proof. Funky unicode stuff is now appearing
everywhere (I’ve seen emoji being used for variable names) and the situation
could be different a couple of years down the line.
>>> 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.
Sure, converting all keys in parsebib is not attractive.
>>> 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.
Not a big deal. Since it’s just about individual entries and the code isn’t
super central, we can easily hack something.
>>>> - 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.
The organically grown parsing code in the Bibtex completion has been bugging me
for a while. So I'm keen on rewriting this. But I may not get to it until the
summer. I'll keep you posted when I start working on it.
Titus
Re: CSL-JSON support for =parsebib=
On 2021-05-07 Fri 14:34, Joost Kremers wrote:
> 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...
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.
>> 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.
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.
>> 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.
Wasn’t aware. Fantastic!
>> - 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?
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.
>> - Functions for resolving strings and cross-references.
>
> This, too, is something that parsebib already does.
OMG, bibtex-completion is doing this as well, but I’d be happy to get rid of
this code.
> 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.
Seems like there’s quite a bit of potential for streamlining bibtex-completion.
Now I just need a week to work on it. :)
Titus
[1] https://www.gnu.org/software/emacs/manual/html_node/elisp/Symbol-Type.html
Re: CSL-JSON support for =parsebib=
Hi all, I’m the maintainer of bibtex-completion, helm-bibtex, and ivy-bibtex. My name is actually Titus, not Theo ;) Cool to see that the ecosystem around academic writing in org mode is developing so nicely. I use org mode for this purpose every single working day and it’s amazing already. I have to confess, though, that I haven’t been keeping up with recent developments. I just saw the recent thread about the citation syntax. (Thanks to Bruce D’Arcus for pointing me to it.) Is there a good place where I can read up on the current efforts and plans regarding citations, bibliographies and so on (I mean other than reading the last couple of months of the mailing list archive)? 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. 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`.) Third, as you say, it would also be nice to maintain compatibility with bibtex.el. Finally, it’s not necessarily clear that avoiding the conversion to strings saves sufficiently many CPU cycles to justify the effort. (But this may be a non-issue anyway, if the JSON parser can return strings directly.) Having said that, I’d be happy to merge a PR that that implements the switch to symbols in bibtex-completion if that’s the consensus. Touches a substantial number of lines, but should nonetheless be relatively straightforward. 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 but things would become messy. (It’s already a bit ugly, I have to say, which is entirely my fault.) It might be more elegant to have a higher-level API in parsebib. This API could perhaps even abstract away from the underlying format (BibTeX, CSL-JSON, or others in the future?). This would substantially simplify matters in bibtex-completion, but would also enable many other cool uses of parsebib. Some rough ideas for such an API (just for illustration): - A function that returns all entries in a .bib or CSL-JSON file. - A function that returns an entry with a specific key (or multiple entries). - Functions for resolving strings and cross-references. So much for now. Titus On 2021-05-07 Fri 11:17, Joost Kremers wrote: > 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
Re: How to preserve empty headings
On 2020-11-30 Mon 19:25, Diego Zamboni wrote: >> >> I’m aware of several workarounds and this one is perhaps the best. >> However, I’d prefer if RET would just work as expected. Org sometimes >> inserts extra material on RET which I think is okay (e.g. indentation), but >> is there any precedent, in Org or Emacs more broadly, for RET deleting >> text? It seems very counter-intuitive to me. >> > > Could it be that the space is being deleted not when you press RET but > when you save the file? I don't see any space deletion when entering an > empty headline, but in my config, whitespace at end of lines is deleted > on save. In Doom Emacs this is enabled by default, and even before I was > using =delete-trailing-whitespace= as part of my =before-save-hook=. Your comment has put me on the right track. The line-final whitespace was not deleted by org but by electric-indent-mode, which apparently does this by default. Sorry for the noise! Titus
Re: How to preserve empty headings
On 2020-11-30 Mon 19:25, Diego Zamboni wrote: >> >> I’m aware of several workarounds and this one is perhaps the best. >> However, I’d prefer if RET would just work as expected. Org sometimes >> inserts extra material on RET which I think is okay (e.g. indentation), but >> is there any precedent, in Org or Emacs more broadly, for RET deleting >> text? It seems very counter-intuitive to me. >> > > Could it be that the space is being deleted not when you press RET but > when you save the file? I don't see any space deletion when entering an > empty headline, but in my config, whitespace at end of lines is deleted > on save. In Doom Emacs this is enabled by default, and even before I was > using =delete-trailing-whitespace= as part of my =before-save-hook=. > --Diego The space is deleted immediately. But the fact that it’s not happening on your system perhaps means that there *is* a setting that prevents it. The question is: which? By the way, I’m using the master branch from https://code.orgmode.org/bzg/org-mode.git as installed by straight.el. Titus
Re: How to preserve empty headings
On 2020-11-30 Mon 18:31, Berry, Charles wrote: >> On Nov 30, 2020, at 9:21 AM, Titus von der Malsburg >> wrote: >> >> >> When I start a new line with '* ' followed by RET, the space is >> automatically deleted and I’m left with a line that just has the asterisk >> (i.e. not a headline). >> >> Unfortunately there are use cases where empty headlines make sense and they >> occur often in my work. One example is Beamer slides where each headline at >> some level produces a slide. If the user needs a slide without title >> (common, e.g., for a large images that fill the slide), an empty headline is >> needed. >> >> Is there a way to teach Org to leave the empty headline intact? >> >> I may be old-fashioned but when I type '* ', I do it for a reason and I wish >> that my text editor respects that. :) >> > > > Instead of `* SPACE RET', try `* SPACE C-j'. I’m aware of several workarounds and this one is perhaps the best. However, I’d prefer if RET would just work as expected. Org sometimes inserts extra material on RET which I think is okay (e.g. indentation), but is there any precedent, in Org or Emacs more broadly, for RET deleting text? It seems very counter-intuitive to me. Titus
How to preserve empty headings
When I start a new line with '* ' followed by RET, the space is automatically deleted and I’m left with a line that just has the asterisk (i.e. not a headline). Unfortunately there are use cases where empty headlines make sense and they occur often in my work. One example is Beamer slides where each headline at some level produces a slide. If the user needs a slide without title (common, e.g., for a large images that fill the slide), an empty headline is needed. Is there a way to teach Org to leave the empty headline intact? I may be old-fashioned but when I type '* ', I do it for a reason and I wish that my text editor respects that. :) Titus
Don’t select-frame after Babel export
When I export an org document to PDF via Babel, the frame is select at the end of the process. Is there a way to prevent this? Example: 1. Request exporting the following org file to PDF via `C-e C-p`: This is a test: #+BEGIN_SRC elisp :eval yes :exports both (sit-for 3) (print "Done!") #+END_SRC 2. Then immediately iconify the Emacs frame. 3. Wait until the end of the 3 seconds. Result: The Emacs frame will be raised and focused. Background: I often export computation-heavy org documents and work on something else in the meantime. I don’t want Emacs to interfere with that other work when it’s done exporting. Titus
Re: [PATCH] lisp/org.el: Allow hiding #+SUBTITLE: keyword via `org-hidden-keywords'
On 2020-11-16 Mo 06:33, Kyle Meyer wrote: > Titus von der Malsburg writes: > >> Subject: [PATCH] lisp/org.el: Allow hiding #+SUBTITLE: keyword via >> `org-hidden-keywords' >> >> * lisp/org.el: Allow users to include 'subtitle in >> `org-hidden-keywords' to hide #+SUBTITLE: keyword. >> >> This way #+SUBTITLE is treated like similar keywords for title, date, >> e-mail, and author. > > Thanks, sounds good. > >> --- >> lisp/org.el | 1 + >> 1 file changed, 1 insertion(+) > > Could you add an entry to ORG-NEWS? Done. >> diff --git a/lisp/org.el b/lisp/org.el >> index 73b270712..0d2fbddda 100644 >> --- a/lisp/org.el >> +++ b/lisp/org.el >> @@ -3573,6 +3573,7 @@ appear in the buffer without the initial \"#+TITLE:\" >> part." >>:type '(set (const :tag "#+AUTHOR" author) >>(const :tag "#+DATE" date) >>(const :tag "#+EMAIL" email) >> + (const :tag "#+SUBTITLE" subtitle) >>(const :tag "#+TITLE" title))) > > Please add > > :package-version '(Org . "9.5") > > dropping the current ':version "24.1"'. Done. Updated patch attached. Thanks for your guidance. Titus >From fc3957aad8c94d1b1f3f1882c9f5d6da4552b640 Mon Sep 17 00:00:00 2001 From: Titus von der Malsburg Date: Mon, 16 Nov 2020 11:05:15 +0100 Subject: [PATCH] lisp/org.el: Allow hiding #+SUBTITLE: keyword via `org-hidden-keywords' * lisp/org.el: Allow users to include 'subtitle in `org-hidden-keywords' to hide #+SUBTITLE: keyword. This way #+SUBTITLE is treated like similar keywords for title, date, e-mail, and author. --- etc/ORG-NEWS | 6 ++ lisp/org.el | 3 ++- 2 files changed, 8 insertions(+), 1 deletion(-) diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS index 66347fe90..889eb4aab 100644 --- a/etc/ORG-NEWS +++ b/etc/ORG-NEWS @@ -12,6 +12,12 @@ Please send Org bug reports to mailto:emacs-orgmode@gnu.org. * Version 9.5 (not yet released) ** New options and settings +*** Option ~org-hidden-keywords~ now also applies to #+SUBTITLE: + +The option ~org-hidden-keywords~ previously applied +to #+TITLE:, #+AUTHOR:, #+DATE:, and #+EMAIL:. Now it can also be +used to hide the #+SUBTITLE: keyword. + *** New formatting directive ~%L~ for org-capture The new ~%L~ formatting directive contains the bare link target, and diff --git a/lisp/org.el b/lisp/org.el index 73b270712..2b50f94ee 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -3569,10 +3569,11 @@ lines to the buffer: For example, a value \\='(title) for this list makes the document's title appear in the buffer without the initial \"#+TITLE:\" part." :group 'org-appearance - :version "24.1" + :package-version '(Org . "9.5") :type '(set (const :tag "#+AUTHOR" author) (const :tag "#+DATE" date) (const :tag "#+EMAIL" email) + (const :tag "#+SUBTITLE" subtitle) (const :tag "#+TITLE" title))) (defcustom org-custom-properties nil -- 2.25.1 -- Dr. Titus von der Malsburg Dept. Linguistics, University of Potsdam Dept. Brain & Cognitive Sciences, MIT https://tmalsburg.github.io PGP fingerprint: C34C 7364 EAAD 4752 FABA 35E6 AE34 59F3 C613 689D
Re: [PATCH] lisp/org.el: Use `org-document-info' face for subtitles
On 2020-11-07 Sa 23:04, Kyle Meyer wrote:
> Titus von der Malsburg writes:
>
>> On 2020-11-06 Fr 07:18, Kyle Meyer wrote:
>>> Titus von der Malsburg writes:
>>>
>>>> Subject: [PATCH] lisp/org.el: Use face org-document-info for subtitle
>>>>
>>>> * lisp/org.el: The value for the #+subtitle: property is now displayed
>>>> with face `org-document-info' instead of `org-meta-line'.
>>>>
>>>> Like the title, author, e-mail, date, the subtitle is information
>>>> that is displayed in the exported document.
>>>
>>> Makes sense to me, and I guess it was left out just because #+subtitle
>>> wasn't around until v8.3.
>>>
>>>> ---
>>>> lisp/org.el | 2 +-
>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>>
>>>> diff --git a/lisp/org.el b/lisp/org.el
>>>> index 03df139fb..27f09645b 100644
>>>> --- a/lisp/org.el
>>>> +++ b/lisp/org.el
>>>> @@ -5307,7 +5307,7 @@ by a #."
>>>> (min (point-max) end-of-endline))
>>>> '(face org-block-end-line)))
>>>>t))
>>>> - ((member dc1 '("+title:" "+author:" "+email:" "+date:"))
>>>> + ((member dc1 '("+title:" "+subtitle:" "+author:" "+email:" "+date:"))
>>>> (org-remove-flyspell-overlays-in
>>>> (match-beginning 0)
>>>> (if (equal "+title:" dc1) (match-end 2) (match-end 0)))
>>>
>>> Please also update org-document-info-keyword's docstring.
>>
>> Done. I also updated the docstring for `org-document-info'. See attached
>> patch.
>
> Thanks. Applied (e2fe59683), add entries to the changelog for the
> faces.
Attached is a follow-up patch that allows users to hide the #+SUBTITLE: keyword
via `org-hidden-keywords' just like #+TITLE, #+AUTHOR:, and similar.
Titus
>From 794e126fa1ab3cebc8de3bf35324e8353bc8a427 Mon Sep 17 00:00:00 2001
From: Titus von der Malsburg
Date: Thu, 12 Nov 2020 18:03:33 +0100
Subject: [PATCH] lisp/org.el: Allow hiding #+SUBTITLE: keyword via
`org-hidden-keywords'
* lisp/org.el: Allow users to include 'subtitle in
`org-hidden-keywords' to hide #+SUBTITLE: keyword.
This way #+SUBTITLE is treated like similar keywords for title, date,
e-mail, and author.
---
lisp/org.el | 1 +
1 file changed, 1 insertion(+)
diff --git a/lisp/org.el b/lisp/org.el
index 73b270712..0d2fbddda 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -3573,6 +3573,7 @@ appear in the buffer without the initial \"#+TITLE:\" part."
:type '(set (const :tag "#+AUTHOR" author)
(const :tag "#+DATE" date)
(const :tag "#+EMAIL" email)
+ (const :tag "#+SUBTITLE" subtitle)
(const :tag "#+TITLE" title)))
(defcustom org-custom-properties nil
--
2.25.1
Re: How to set options for verbatim environments produced by org babel
Thanks, Eric. I didn’t know results could be detached from their code blocks
via names. That’s really useful.
However, a clean way to pass options to the verbatim (or listing) environment
used for displaying results would be great nonetheless.
Titus
On 2020-11-09 Mo 13:23, Eric S Fraga wrote:
> On Monday, 9 Nov 2020 at 12:28, Titus von der Malsburg wrote:
>> Is there a way to set options for the verbatim environment in Org mode?
>
> I cannot answer your actual question but I achieve the same outcome in a
> different manner. I name my src blocks and then add LaTeX directives to
> the output as required:
>
> #+begin_src org
> ,#+name: rblock
> ,#+BEGIN_SRC octave :exports results :results value output
> 1+2
> ,#+END_SRC
>
> ,#+latex: {\small
> ,#+results: rblock
> : ans = 3
> ,#+latex: }
> #+end_src
>
> (I had to change your example to octave as I don't have R installed ;-))
>
> I do this all the time with beamer in particular to get output in my
> teaching slides.
>
> HTH,
> eric
>
> --
> : Eric S Fraga via Emacs 28.0.50, Org release_9.4-61-ga88806.dirty
--
Dr. Titus von der Malsburg
Dept. Linguistics, University of Potsdam
Dept. Brain & Cognitive Sciences, MIT
https://tmalsburg.github.io
PGP fingerprint: C34C 7364 EAAD 4752 FABA 35E6 AE34 59F3 C613 689D
How to set options for verbatim environments produced by org babel
I’m using the ~Verbatim~ environment from the fancyvrb package to display Org
Babel results in my Beamer slides. The ~Verbatim~ environment accepts options
for setting the font size among other things. This is useful when the output
of a code block has longer lines that do not fit on a slide.
Is there a way to set options for the verbatim environment in Org mode?
Example: This Org source
#+BEGIN_SRC R :exports results :results value output
1+2
#+END_SRC
exports to
\begin{verbatim}
3
\end{verbatim}
But I’d like to be able to translate something like this:
#+BEGIN_SRC R :exports results :results value output :options
[fontsize=\small]
1+2
#+END_SRC
to
\begin{verbatim}[fontsize=\small]
3
\end{verbatim}
I’m sure there is a way to do this but couldn’t find it.
Titus
Re: [PATCH] lisp/org.el: Use `org-document-info' face for subtitles
On 2020-11-06 Fr 07:18, Kyle Meyer wrote:
> Titus von der Malsburg writes:
>
>> Subject: [PATCH] lisp/org.el: Use face org-document-info for subtitle
>>
>> * lisp/org.el: The value for the #+subtitle: property is now displayed
>> with face `org-document-info' instead of `org-meta-line'.
>>
>> Like the title, author, e-mail, date, the subtitle is information
>> that is displayed in the exported document.
>
> Makes sense to me, and I guess it was left out just because #+subtitle
> wasn't around until v8.3.
>
>> ---
>> lisp/org.el | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/lisp/org.el b/lisp/org.el
>> index 03df139fb..27f09645b 100644
>> --- a/lisp/org.el
>> +++ b/lisp/org.el
>> @@ -5307,7 +5307,7 @@ by a #."
>> (min (point-max) end-of-endline))
>> '(face org-block-end-line)))
>> t))
>> - ((member dc1 '("+title:" "+author:" "+email:" "+date:"))
>> + ((member dc1 '("+title:" "+subtitle:" "+author:" "+email:" "+date:"))
>>(org-remove-flyspell-overlays-in
>> (match-beginning 0)
>> (if (equal "+title:" dc1) (match-end 2) (match-end 0)))
>
> Please also update org-document-info-keyword's docstring.
Done. I also updated the docstring for `org-document-info'. See attached
patch.
Titus
>From 3d27f195a635f9ef8cbf43e1549663bef447c8fa Mon Sep 17 00:00:00 2001
From: Titus von der Malsburg
Date: Tue, 3 Nov 2020 10:32:57 +0100
Subject: [PATCH] lisp/org.el: Display subtitle lines with document info faces
* lisp/org.el: The #+SUBTITLE: keyword is now displayed with
`org-document-info-keyword' and its value with
`org-document-info' (instead of `org-meta-line').
Like the title, author, e-mail, date, the subtitle is information
that is displayed in the exported document, not meta information.
---
lisp/org-faces.el | 8 +---
lisp/org.el | 2 +-
2 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/lisp/org-faces.el b/lisp/org-faces.el
index 94b283ad6..2f3273f55 100644
--- a/lisp/org-faces.el
+++ b/lisp/org-faces.el
@@ -414,12 +414,14 @@ changes."
'class color) (background light)) (:foreground "midnight blue"))
(((class color) (background dark)) (:foreground "pale turquoise"))
(t nil))
- "Face for document date, author and email; i.e. that which
-follows a #+DATE:, #+AUTHOR: or #+EMAIL: keyword."
+ "Face for document subtitle, date, author and email; i.e. that
+which follows a #+SUBTITLE:, #+DATE:, #+AUTHOR: or #+EMAIL:
+keyword."
:group 'org-faces)
(defface org-document-info-keyword '((t :inherit shadow))
- "Face for #+TITLE:, #+AUTHOR:, #+EMAIL: and #+DATE: keywords."
+ "Face for #+TITLE:, #+SUBTITLE:, #+AUTHOR:, #+EMAIL: and
+#+DATE: keywords."
:group 'org-faces)
(defface org-block `((t :inherit shadow
diff --git a/lisp/org.el b/lisp/org.el
index 9a13f03d6..89cb09fe1 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -5307,7 +5307,7 @@ by a #."
(min (point-max) end-of-endline))
'(face org-block-end-line)))
t))
- ((member dc1 '("+title:" "+author:" "+email:" "+date:"))
+ ((member dc1 '("+title:" "+subtitle:" "+author:" "+email:" "+date:"))
(org-remove-flyspell-overlays-in
(match-beginning 0)
(if (equal "+title:" dc1) (match-end 2) (match-end 0)))
--
2.25.1
[PATCH] lisp/org.el: Use `org-document-info' face for subtitles
Org currently uses `org-meta-line' to display the value of the #+subtitle:
property. However, the subtitle isn’t meta information, but document
information supposed to be displayed in the exported document like title,
author, date, e-mail. The attached patch uses the face `org-document-info' to
display subtitles, which is the same face as for title, author, date, e-mail.
Titus
>From ffb43ad434031ff0ae335711d7ac29c8a4973417 Mon Sep 17 00:00:00 2001
From: Titus von der Malsburg
Date: Tue, 3 Nov 2020 10:32:57 +0100
Subject: [PATCH] lisp/org.el: Use face org-document-info for subtitle
* lisp/org.el: The value for the #+subtitle: property is now displayed
with face `org-document-info' instead of `org-meta-line'.
Like the title, author, e-mail, date, the subtitle is information
that is displayed in the exported document.
---
lisp/org.el | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lisp/org.el b/lisp/org.el
index 03df139fb..27f09645b 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -5307,7 +5307,7 @@ by a #."
(min (point-max) end-of-endline))
'(face org-block-end-line)))
t))
- ((member dc1 '("+title:" "+author:" "+email:" "+date:"))
+ ((member dc1 '("+title:" "+subtitle:" "+author:" "+email:" "+date:"))
(org-remove-flyspell-overlays-in
(match-beginning 0)
(if (equal "+title:" dc1) (match-end 2) (match-end 0)))
--
2.25.1
Re: [O] Bug: Bug: org-in-item-p indicates point is in list when it isn't [8.3.3 (release_8.3.3-529-gfed40e @ /home/malsburg/usr/share/emacs/site-lisp/org/)] [9.0.5 (9.0.5-elpa @ /home/malsburg/.emacs.
On 2017-05-21 Sun 12:57, Nicolas Goaziou wrote: > Hello, > > Titus von der Malsburg <malsb...@posteo.de> writes: > >> In the example below, when I place the cursor on “Item 2” and then do >> (org-end-of-item-list), the cursor is correctly placed at the beginning >> of line 4. However, when I then say (org-in-item-p), I get something >> non-nil. When I move the cursor to the beginning of line 5, I still get >> non-nil for (org-in-item-p). The expected result is nil on line 4 and >> 5. If (org-in-item-p) gives non-nil, (org-end-of-item-list) has >> obviously not moved us to the end of the list. I think >> (org-end-of-item-list) is doing the right thing but (org-in-item-p) >> doesn’t. > > I don't see any bug. Blank lines after a plain list still belong to the > plain list, so `org-in-item-p' is correct. > > Indeed, `org-end-of-item-list' moves to the end of the last item No, it does not move us to the end of the item. That’s precisely the problem. org-in-item-p returns non-nil even for positions after the point to which org-end-of-item-list takes us. > instead > of the very end of the list, but I consider it to be a feature, e.g., > when you need to exchange two items in the list. > > You may want to explain what is bothering you in this results. The documentation of org-end-of-item-list says: Go to the end of the current list or sublist. However, when I call this function and then move the point one line further down in the example, org-in-item-p still says I’m in the list. It logically follows that org-end-of-item-list did not take me to the end of the list, contrary to what the documentation says. It may be convenient that org-end-of-item-list doesn’t take us to the very end of the list (in my use case it’s not), but that behavior is clearly neither consistent with the name of the function nor with its documentation. According to the documentation, org–end-of-item-list should take us to the last position where org-in-item-p returns non-nil. Since it doesn’t, there is a bug, either in the implementation or in the documentation. > Also, I suggest to use `org-element-at-point' instead. Thanks. In the meantime, I had found org-list-struct which also solves my problem. Titus
[O] Bug: Bug: org-in-item-p indicates point is in list when it isn't [8.3.3 (release_8.3.3-529-gfed40e @ /home/malsburg/usr/share/emacs/site-lisp/org/)] [9.0.5 (9.0.5-elpa @ /home/malsburg/.emacs.d/el
In the example below, when I place the cursor on “Item 2” and then do (org-end-of-item-list), the cursor is correctly placed at the beginning of line 4. However, when I then say (org-in-item-p), I get something non-nil. When I move the cursor to the beginning of line 5, I still get non-nil for (org-in-item-p). The expected result is nil on line 4 and 5. If (org-in-item-p) gives non-nil, (org-end-of-item-list) has obviously not moved us to the end of the list. I think (org-end-of-item-list) is doing the right thing but (org-in-item-p) doesn’t. #+BEGIN_EXAMPLE - Item 1 - Item 2 ** Some headline #+END_EXAMPLE I’m using a recent development version of Emacs and Org-Mode from MELPA. Tested with emacs -q. Until a couple of weeks ago, this problem didn’t occur. I can’t pin down when exactly this happened for the first time. Emacs : GNU Emacs 25.0.93.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.18.9) of 2016-05-14 Package: Org-mode version 8.3.3 (release_8.3.3-529-gfed40e @ /home/malsburg/usr/share/emacs/site-lisp/org/) current state: == (setq org-tab-first-hook '(org-hide-block-toggle-maybe org-babel-hide-result-toggle-maybe org-babel-header-arg-expand) org-speed-command-hook '(org-speed-command-default-hook org-babel-speed-command-hook) org-occur-hook '(org-first-headline-recenter) org-metaup-hook '(org-babel-load-in-session-maybe) org-confirm-shell-link-function 'yes-or-no-p org-after-todo-state-change-hook '(org-clock-out-if-current) org-src-mode-hook '(org-src-babel-configure-edit-buffer org-src-mode-configure-edit-buffer) org-agenda-before-write-hook '(org-agenda-add-entry-text) org-babel-pre-tangle-hook '(save-buffer) org-mode-hook '(#[0 "\300\301\302\303\304$\207" [org-add-hook change-major-mode-hook org-show-block-all append local] 5] #[nil "\300\301\302\303\304$\207" [org-add-hook change-major-mode-hook org-babel-show-result-all append local] 5] org-babel-result-hide-spec org-babel-hide-all-hashes) org-archive-hook '(org-attach-archive-delete-maybe) org-ctrl-c-ctrl-c-hook '(org-babel-hash-at-point org-babel-execute-safely-maybe) org-cycle-hook '(org-cycle-hide-archived-subtrees org-cycle-hide-drawers org-cycle-show-empty-lines org-optimize-window-after-visibility-change) org-confirm-elisp-link-function 'yes-or-no-p org-metadown-hook '(org-babel-pop-to-session-maybe) org-clock-out-hook '(org-clock-remove-empty-clock-drawer) )
Re: [O] Feature request: lists with letters
On 2017-02-09 Thu 09:29, Rasmus wrote:
> Titus von der Malsburg <malsb...@posteo.de> writes:
>
>> That’s a neat hack that might come in handy at some point. However, it
>> changes the bullet point to letters for /all/ ordered lists in the
>> document, not just for those that use letters in the org source.
>
> Yes, I use the simplest possible example. Here's an example that changes
> it for one list at the cost of an extra package.
>
> #+latex_header: \usepackage[shortlabels]{enumitem}
> #+attr_latex: :options [a.]
> 1. one
> 2. two
> 3. three
Again, this is nice and honestly I admire your skill and knowledge. But
this solution only works for LaTeX export and not for HTML and other
targets. When I start writing documents, I often do not even know what
the target is eventually going to be. Also, I often export org to
multiple targets, for example, my lecture notes are usually exported to
HTML and to PDF.
Titus
signature.asc
Description: PGP signature
Re: [O] Feature request: lists with letters
On 2017-02-06 Mon 15:34, Rasmus wrote:
> Titus von der Malsburg <malsb...@posteo.de> writes:
>
>> On 2017-02-03 Fri 12:40, Eric S Fraga wrote:
>>> On Friday, 3 Feb 2017 at 11:37, Titus von der Malsburg wrote:
>>>
>>
>>> [...]
>>>
>>>> For me and many others, this is a very common use case. I challenge you
>>>> to implement this with current Org such that it will export correctly to
>>>> HTML and PDF. If I’m not mistaken, this is non-trivial. If there is no
>>>
>>> #+begin_src org
>>> Sensation, perception, and memory are of particular
>>> interest to which group of contemporary psychologists?
>>>
>>> 1. psychoanalysts
>>> 2. behaviorists
>>> 3. humanistic psychologists
>>> 4. <> cognitive psychologists
>>>
>>> The correct answer is [[answer]] because
>>> #+end_src
>>>
>>> does the job for both LaTeX and HTML although with a number in this
>>> case. I have not tried with alphabetical enumeration.
>>
>> This is nice, but letters are conventionally used in many contexts and I
>> think making it work with letters is much harder.
>
> You could use this:
>
> #+html_head: ol {list-style-type: lower-latin;}
> #+latex_header: \renewcommand{\theenumi}{\alph{enumi}}
>
> The answer link would render wrongly in html, though. I'm don't know if
> there's an easy way to get the correct "label" for a list item with
> html/js.
That’s a neat hack that might come in handy at some point. However, it
changes the bullet point to letters for /all/ ordered lists in the
document, not just for those that use letters in the org source.
I think this shows that it’s indeed too difficult to make lists with
letters although such lists are fairly common and even standard in some
areas. A small change in the exporters could solve this issue and make
Org mode more useful. I don’t see any downsides.
Titus
signature.asc
Description: PGP signature
Re: [O] Feature request: lists with letters
On 2017-02-03 Fri 12:40, Eric S Fraga wrote: > On Friday, 3 Feb 2017 at 11:37, Titus von der Malsburg wrote: > > [...] > >> For me and many others, this is a very common use case. I challenge you >> to implement this with current Org such that it will export correctly to >> HTML and PDF. If I’m not mistaken, this is non-trivial. If there is no > > #+begin_src org > Sensation, perception, and memory are of particular > interest to which group of contemporary psychologists? > > 1. psychoanalysts > 2. behaviorists > 3. humanistic psychologists > 4. <> cognitive psychologists > > The correct answer is [[answer]] because > #+end_src > > does the job for both LaTeX and HTML although with a number in this > case. I have not tried with alphabetical enumeration. This is nice, but letters are conventionally used in many contexts and I think making it work with letters is much harder. Titus -- Dr. Titus von der Malsburg Visiting Professor for Computational Psycholinguistics Department of Linguistics University of Potsdam, Germany https://tmalsburg.github.io PGP fingerprint: C34C 7364 EAAD 4752 FABA 35E6 AE34 59F3 C613 689D GNU Ring ID: ring:a1494601ee7d214bdfd8105dca065aee6d653556 signature.asc Description: PGP signature
Re: [O] Feature request: lists with letters
Eric Abrahamsen wrote: >> Titus von der Malsburg <address@hidden> writes: >> >>> Correct me if I’m wrong but there are a lot of things in Org that are >>> just about typesetting: *bold*, /italic/, _underlined_, =verbatim= and >>> ~code~, +strike-through+. Would you remove these things as well? >> >> I could argue that emphasis is not just about typesetting. It conveys >> a meaning. How emphasis is rendered _is_ typesetting, however. For >> example, "latex" and "beamer" export back-ends render bold text >> differently. > >It's similar to how HTML went from and to and . >The former were presentation directives. The latter are semantic >directives. They're practically the same, for reasons of backwards >compatibility, and conceptual continuity. Org's emphasis markers are >similar -- they *look* like presentation directives, but at this point >they're actually used as semantic directives. Hi Eric, I appreciate that it makes sense to make Org more consistent and to use abstract principles to guide its design. However, I’m not convinced by the analogy to HTML since there are some crucial differences between Org and HTML. First, HTML is not supposed to be read by humans – it is code. In contrast to that, Org is supposed to be human readable and hence, it has to deal with visual presentation to some degree. And it actually does: when I write *bold* in Emacs, a bold font is used. Nicholas’ point that Org’s bold has nothing to do with bold fonts is therefore not entirely correct. Bold clearly means bold in Org, even if the beamer exporter interprets this otherwise (which I always found annoying). Secondly, HTML can afford to be purely semantic because there is CSS to deal with visual presentation. In the case of Org, there is no such thing as CSS, and the only solution is to litter the Org document with LaTeX and HTML code. Not appealing at all in my opinion. Here is an example to illustrate this: #+BEGIN_SRC org Sensation, perception, and memory are of particular interest to which group of contemporary psychologists? a. psychoanalysts b. behaviorists c. humanistic psychologists d. cognitive psychologists The correct answer is d. because … #+END_SRC For me and many others, this is a very common use case. I challenge you to implement this with current Org such that it will export correctly to HTML and PDF. If I’m not mistaken, this is non-trivial. If there is no clean and simple solution for this, this strongly suggests that Org should do the pragmatic thing and support alphabetic bullet points in its exporters. More generally, I’m not convinced by the philosophy that Org should be purely semantic markup and that its syntax should be changed to enforce this even if this breaks existing documents (Nicholas’ preferred solution). Org clearly has a certain WYSIWYG quality and precisely that is one of the reasons for its success. We should embrace the fact that Org is differnt from HTML and not force it to be something that it isn’t. Titus signature.asc Description: PGP signature
Re: [O] Feature request: lists with letters
On 2017-02-02 Thu 19:57, Nicolas Goaziou wrote: > Hello, > > Titus von der Malsburg <malsb...@posteo.de> writes: > >> One issue with org-list-allow-alphabetical is that we get numbers >> instead of letters when we export to HTML and LaTeX. I saw the earlier >> thread [0] that gives the reasoning for this but I find it >> unsatisfying. If Org allows us to distinguish between -, +, 1., 1), a., >> A., a), A), this should also be honored by the exporter. > > This is also why I dislike the feature. > >> Otherwise it’s rather pointless to allow that distinction in the first >> place. > > Exactly. > >> IMHO, a clean solution would be to either drop everything but - and >> 1. or to keep all these and make the exporters honor them. The former >> would breaks existing documents and is therefore out of the >> question. This leaves us with the second solution. > > I wouldn't rule that out. Breaking changes happen. We can provide tools > to fix existing documents. > > Actually, I like the idea of keeping only "-" and "1.". We could > implement other bullet types as overlays. > >> Any chance you are willing to reconsider the decision to ignore >> allow-alphabetical during export? > > I still agree with Carsten in the thread you pointed out. Org document > is about structure. The bullet in about typesetting. Correct me if I’m wrong but there are a lot of things in Org that are just about typesetting: *bold*, /italic/, _underlined_, =verbatim= and ~code~, +strike-through+. Would you remove these things as well? Titus >> I think it would be very useful to have that. I know there are other >> ways to get alphabetical bullets in exported documents but they are >> all specific to certain export targets and the beauty of Org mode is >> precisely that we can export to many different targets. > > The beauty of Org is also to allow to control different export targets > in the same document. > > I think this is a non-issue. > > Regards, > > -- > Nicolas Goaziou0x80A93738 -- Dr. Titus von der Malsburg Visiting Professor for Computational Psycholinguistics Department of Linguistics University of Potsdam, Germany https://tmalsburg.github.io PGP fingerprint: C34C 7364 EAAD 4752 FABA 35E6 AE34 59F3 C613 689D GNU Ring ID: ring:a1494601ee7d214bdfd8105dca065aee6d653556 signature.asc Description: PGP signature
Re: [O] Feature request: lists with letters
On 2017-02-02 Thu 17:55, Nicolas Goaziou wrote: > Hello, > > Titus von der Malsburg <malsb...@posteo.de> writes: > >> Items in lists can start with -, +, N), or N. (with N being an >> integer). It’s currently not possible, to use letters as in the >> following examples: >> >> a. First item >> b. Second item >> >> or >> >> a) First item >> b) Second item >> >> I believe it would make sense to allow letters in org-mode because >> that’s a very common way to label items in lists. I know that this has >> been discussed previously but to my knowledge there was no >> resolution. The counter argument against letters was that we wouldn’t >> know what labels to use when there are more items than letters, but I >> think this shouldn’t stop us. Reasons: >> >> a) Most lists have fewer items and cases where more than 26 labels are >>needed are rare. >> b) If a list has more than 26 items, the user is free to switch to >>bullet points or numbers. >> c) The limited number of letters hasn’t stopped people from using >>letters in many other contexts. For example, LaTeX offers letters >>and people think it’s useful. >> d) Similarly, people often use Roman numerals (e.g., iv.) although >>they also quickly become impractical (999 = CMXCIX). >> e) In some (academic) contexts, e.g. in linguistics, letters are >>conventionally used to label items in lists. >> f) Letters worked perfectly fine in this list. >> >> As to the question what org mode should do if a list is two long for >> letters: Here are two possible solutions: >> >> a) Label all items beyond the 26th with z, to make it visually very >>salient that there are not enough letters. >> b) Start over from letter a after z. >> c) Count in base 26 using letters as digits: a … z aa … az ba … bz … >> >> Personally, I would prefer solution c because it gives each item a >> unique label to which we can refer. But solutions a and b would be ok, >> too. It doesn’t really matter because this is just an uninteresting >> edge case and we shouldn’t obsess about it when the default case (<=26 >> items) is complete unproblematic. >> >> Thanks for considering this proposal. > > This proposal was implemented exactly 6 years ago. See > `org-list-allow-alphabetical'. > > They introduce false positives, so they are not allowed by default. > Also, they probably should be implemented visually (i.e., with overlays, > à la `org-bullets') not syntactically. Anyway, here they are. Great, and thanks for the response. I had actually checked the documentation but it’s very easy to overlook the footnote in which this is mentioned. One issue with org-list-allow-alphabetical is that we get numbers instead of letters when we export to HTML and LaTeX. I saw the earlier thread [0] that gives the reasoning for this but I find it unsatisfying. If Org allows us to distinguish between -, +, 1., 1), a., A., a), A), this should also be honored by the exporter. Otherwise it’s rather pointless to allow that distinction in the first place. IMHO, a clean solution would be to either drop everything but - and 1. or to keep all these and make the exporters honor them. The former would breaks existing documents and is therefore out of the question. This leaves us with the second solution. Any chance you are willing to reconsider the decision to ignore allow-alphabetical during export? I think it would be very useful to have that. I know there are other ways to get alphabetical bullets in exported documents but they are all specific to certain export targets and the beauty of Org mode is precisely that we can export to many different targets. Thank you for your work on Org mode. I use it for everything and without it, I just wouldn’t know what to do. Titus [0] https://lists.gnu.org/archive/html/emacs-orgmode/2013-06/msg00221.html signature.asc Description: PGP signature
[O] Feature request: lists with letters
Items in lists can start with -, +, N), or N. (with N being an integer). It’s currently not possible, to use letters as in the following examples: a. First item b. Second item or a) First item b) Second item I believe it would make sense to allow letters in org-mode because that’s a very common way to label items in lists. I know that this has been discussed previously but to my knowledge there was no resolution. The counter argument against letters was that we wouldn’t know what labels to use when there are more items than letters, but I think this shouldn’t stop us. Reasons: a) Most lists have fewer items and cases where more than 26 labels are needed are rare. b) If a list has more than 26 items, the user is free to switch to bullet points or numbers. c) The limited number of letters hasn’t stopped people from using letters in many other contexts. For example, LaTeX offers letters and people think it’s useful. d) Similarly, people often use Roman numerals (e.g., iv.) although they also quickly become impractical (999 = CMXCIX). e) In some (academic) contexts, e.g. in linguistics, letters are conventionally used to label items in lists. f) Letters worked perfectly fine in this list. As to the question what org mode should do if a list is two long for letters: Here are two possible solutions: a) Label all items beyond the 26th with z, to make it visually very salient that there are not enough letters. b) Start over from letter a after z. c) Count in base 26 using letters as digits: a … z aa … az ba … bz … Personally, I would prefer solution c because it gives each item a unique label to which we can refer. But solutions a and b would be ok, too. It doesn’t really matter because this is just an uninteresting edge case and we shouldn’t obsess about it when the default case (<=26 items) is complete unproblematic. Thanks for considering this proposal. Titus
Re: [O] Problem with org-babel-detangle
On 2016-02-02 Tue 14:29, Nicolas Goaziou wrote: > Hello, > > Titus von der Malsburg <malsb...@posteo.de> writes: > >> If I open the org-buffer and the tangled files side by side, and then >> detangle, both windows show the org-buffer afterwards. I think >> detangling should leave the buffers alone. Perhaps there is a misplaced >> save-excursion somewhere? > > I cannot reproduce it, but I assume it comes from your > `org-src-window-setup' setting. Hm, I haven’t changed the value of `org-src-window-setup' from its default (which is `reorganize-frame'). I will look into it. Titus > For some > reason,`org-babel-tangle-jump-to-org' calls `org-src-switch-to-buffer'. > > Regards, signature.asc Description: PGP signature
Re: [O] ox-tufte-latex
Hi Tom, thanks for sharing this. I’m looking forward to using it. Do you happen to have an example file that showcases the features? Titus On 2016-02-01 Mon 16:26, Thomas S. Dye wrote: > Aloha all, > > I've cobbled together an exporter for the Tufte LaTeX classes, which I'd > like to contribute to Org mode contrib/. A brief description of the > derived backend can be found below, and I've attached the > ox-tufte-latex.el file for the review described on > http://orgmode.org/worg/org-contribute.html. > > I've been using the derived backend for a while now and am happy with > how it is working. The Tufte LaTeX classes (especially the book class) > require quite a bit of set up to work optimally, and I'll be sharing > what I've learned along these lines in the next couple of weeks. Org > mode is a great tool for authoring Tufte LaTeX documents! > > All the best, > Tom > > > OX-TUFTE-LATEX > > Thomas S. Dye > > > > The file `ox-tufte-latex.el' implements an Org mode export backend for > the Tufte LaTeX classes, which are designed to produce books and > handouts in the style developed by Edward Tufte. The backend is derived > from `ox-latex.el'. > > A characteristic of Tufte's style is a page layout with a wide margin on > one side (typically the right side) in which notes, references, small > tables, and small figures are placed. > > The Tufte LaTeX classes implement several non-standard LaTeX commands to > achieve this page layout, including `marginfigure', `margintable', and > `sidenote'. `Ox-tufte-latex.el' implements these commands. > > The `marginfigure' command is controlled by a new LaTeX attribute > `:float margin'. In addition, there are attributes to: set the offset, > e.g., `:offset 1in', which adjusts the position of the figure up or down > in the margin; the vertical alignment of figure captions, e.g., > `:vertical-alignment t|b', so they align with either the top or bottom > of the float; and `:horizontal-alignment l|r' in case a figure and its > caption end up on different pages. > > The `margintable' command is controlled by the LaTeX attribute `:float > margin' associated with a table. > > The Org mode footnote mechanism has been hijacked to produce `sidenote' > commands, instead of `footnote' commands. The `sidenote' command takes > an optional parameter for the offset, and this is implemented as a LaTeX > attribute associated with the Org mode footnote definition, e.g., > ┌ > │ #+attr_latex: :offset 36pt > │ [fn:1] Cook referred to Koa`a as Koah. > └ signature.asc Description: PGP signature
[O] Bug: org-babel-tangle fails with :comments org [8.3beta (release_8.3beta-1286-g20795f @ /home/malsburg/usr/share/emacs/site-lisp/org/)]
Remember to cover the basics, that is, what you expected to happen and
what in fact did happen. You don't know how to make a good report? See
http://orgmode.org/manual/Feedback.html#Feedback
Your bug report will be posted to the Org-mode mailing list.
I used the following org-mode document:
#+PROPERTY: header-args:R :tangle yes :comments org
* Test
Text for testing.
#+BEGIN_SRC R
message(1)
#+END_SRC
#+BEGIN_SRC R
message(2)
#+END_SRC
When I `org-babel-tangle', this fails after the first code block is
written. Stacktrace below. Tested with current development versions of
Emacs and org-mode.
Debugger entered--Lisp error: (error "Nothing to comment")
signal(error ("Nothing to comment"))
error("Nothing to comment")
comment-region-default(1 3 nil)
comment-region(1 3)
#[(text) "\205&\303\230?\205& G\304V\205&\n\203 c\207\305`
c\210`\"\210\306\210\307c\207" [comments text
org-babel-tangle-uncomment-comments "no" 0 comment-region nil "\n"] 3](#("\n\n"
0 1 (font-lock-fontified t fontified t face org-block-end-line) 1 2
(font-lock-fontified t fontified t)))
org-babel-spec-to-string((12 "/tmp/test2.org" "file:/tmp/test2.org::*Test"
Test:1 ((:colname-names) (:rowname-names) (:result-params "replace")
(:result-type . value) (:comments . "org") (:shebang . "") (:cache . "no")
(:padline . "") (:noweb . "no") (:tangle . "yes") (:exports . "code") (:results
. "replace") (:hlines . "no") (:session . "none")) "message(2)" #("\n\n" 0 1
(font-lock-fontified t fontified t face org-block-end-line) 1 2
(font-lock-fontified t fontified t
#[(spec) "\306\211\307!\310!\211G\311V\205 \n)\312! \313\230\203%\314\315
!\2027\316\230\203/\317\2027 G\311V\2057 \211\205P,\203O
\313\230\203O
\320,Q\202P
\211-\205\321!\322-!.\211/\203w.\203w/\316\230\204w\323.\324\"\210*\325-!\203\217-\326\327*\"\235\204\217\330-!\210\331\332!0r0q\210\333\216\3341!\203\247\317\335\336\217\210 \203\277-2\235\204\277 \337Pc\210-2B2\3403!\210\341
4\331\332!5r5q\210\342\216\325-!\203\340\343-!\210db\210\344\345\34638\"A\316\230\204\371`eU\204\371\337c\2104c\210\347\317\211-#\210. \203\f\204\3506T6\351\352-\fB\317\353$.\207"
[get-spec tangle sheb she-bang tangle-mode base-name #[(name) "\302\303
8\"A\207" [name spec assoc 4] 4] :tangle :shebang 0 :tangle-mode "yes"
file-name-sans-extension buffer-file-name "no" nil "." :mkdirp
file-name-directory make-directory parents file-exists-p mapcar car delete-file
generate-new-buffer " *temp*" ((byte-code "\301!\203\n\302!\210\301\207"
[temp-buffer buffer-name kill-buffer] 2)) fboundp (funcall lang-f) ((error))
"\n" org-babel-spec-to-string buffer-string ((byte-code
"\301!\203\n\302!\210\301\207" [temp-buffer buffer-name kill-buffer] 2))
insert-file-contents assoc :padline 4 write-region 493 add-to-list
path-collector #[(a b) "@ @\232\207" [a b] 2] ext file-name fnd m temp-buffer
lang-f ...] 6]((12 "/tmp/test2.org" "file:/tmp/test2.org::*Test" Test:1
((:colname-names) (:rowname-names) (:result-params "replace") (:result-type .
value) (:comments . "org") (:shebang . "") (:cache . "no") (:padline . "")
(:noweb . "no") (:tangle . "yes") (:exports . "code") (:results . "replace")
(:hlines . "no") (:session . "none")) "message(2)" #("\n\n" 0 1
(font-lock-fontified t fontified t face org-block-end-line) 1 2
(font-lock-fontified t fontified t
mapc(#[(spec) "\306\211\307!\310!\211G\311V\205 \n)\312!
\313\230\203%\314\315 !\2027\316\230\203/\317\2027 G\311V\2057
\211\205P,\203O\313\230\203O
\320,Q\202P
\211-\205\321!\322-!.\211/\203w.\203w/\316\230\204w\323.\324\"\210*\325-!\203\217-\326\327*\"\235\204\217\330-!\210\331\332!0r0q\210\333\216\3341!\203\247\317\335\336\217\210 \203\277-2\235\204\277 \337Pc\210-2B2\3403!\210\341
4\331\332!5r5q\210\342\216\325-!\203\340\343-!\210db\210\344\345\34638\"A\316\230\204\371`eU\204\371\337c\2104c\210\347\317\211-#\210. \203\f\204\3506T6\351\352-\fB\317\353$.\207"
[get-spec tangle sheb she-bang tangle-mode base-name #[(name) "\302\303
8\"A\207" [name spec assoc 4] 4] :tangle :shebang 0 :tangle-mode "yes"
file-name-sans-extension buffer-file-name "no" nil "." :mkdirp
file-name-directory make-directory parents file-exists-p mapcar car delete-file
generate-new-buffer " *temp*" ((byte-code "\301!\203\n\302!\210\301\207"
[temp-buffer buffer-name kill-buffer] 2)) fboundp (funcall lang-f) ((error))
"\n" org-babel-spec-to-string buffer-string ((byte-code
"\301!\203\n\302!\210\301\207" [temp-buffer buffer-name kill-buffer] 2))
insert-file-contents assoc :padline 4 write-region 493 add-to-list
path-collector #[(a b) "@ @\232\207" [a b] 2] ext file-name fnd m temp-buffer
lang-f ...] 6] ((8 "/tmp/test2.org" "file:/tmp/test2.org::*Test" Test:1
((:colname-names) (:rowname-names) (:result-params "replace")
Re: [O] Problem with org-babel-detangle
Thanks for looking into it. Detangling seems to work now but there is one problem left: If I open the org-buffer and the tangled files side by side, and then detangle, both windows show the org-buffer afterwards. I think detangling should leave the buffers alone. Perhaps there is a misplaced save-excursion somewhere? Thanks again, Nicolas! Titus On 2016-01-31 Sun 11:50, Nicolas Goaziou wrote: > Hello, > > Titus von der Malsburg <malsb...@posteo.de> writes: > >> I tangeled the following org-mode file: >> >> #+BEGIN_SRC R :tangle /tmp/test.R :comments link >> 1 + 2 >> #+END_SRC >> >> #+BEGIN_SRC R :tangle /tmp/test.R :comments link >> 3 + 4 >> #+END_SRC >> >> The result was: >> >> ## [[file:test.org][No\ heading:1]] >> 1 + 2 >> ## No\ heading:1 ends here >> >> ## [[file:test.org][No\ heading:2]] >> 3 + 4 >> ## No\ heading:2 ends here >> >> Then I changes “3 + 4” to “3 + 5”, revisited the org buffer, and >> executed `org-babel-detangle'. >> >> Expected behavior: The second code block in org file is updated to contain >> “3 + 5”. >> >> Actual behaviour: I find myself in a buffer containing test.R, the >> cursor is inside the first code block at “1”, the second code block’s >> content in the org buffer is highlighted, and I have an edit buffer for >> that code block. The content of the second code block is not updated. > > Fixed. Thank you. > > Regards, signature.asc Description: PGP signature
Re: [O] Bug: org-babel-tangle fails with :comments org [8.3beta (release_8.3beta-1286-g20795f @ /home/malsburg/usr/share/emacs/site-lisp/org/)]
;n" "Notes" entry (file+olp tmalsburg-agenda-file "Notes") "*
%? %t\n %i" :prepend t)
("p" "Password" entry (file+olp tmalsburg-secrets-file
"Webseiten and Email accounts")
"* %?")
("t" "To do" entry (file+olp tmalsburg-agenda-file "Agenda"
"TODO") "* TODO %?\n %i"
:prepend t)
("m" "May do" entry (file+olp tmalsburg-agenda-file "Agenda"
"MAYDO") "* MAYDO %?\n %i"
:prepend t)
("r" "To read" entry (file+olp tmalsburg-agenda-file "Agenda"
"READ") "* READ %?\n %i"
:prepend t)
("d" "Done" entry (file+olp tmalsburg-agenda-file "Agenda"
"DONE")
"* DONE %?\n CLOSED: %U\n %i" :prepend t)
)
org-after-todo-state-change-hook '(org-clock-out-if-current)
org-latex-format-drawer-function #[514 "\207" [] 3 "\n\n(fn _ CONTENTS)"]
org-capture-mode-hook '(evil-insert-state)
org-from-is-user-regexp "\\"
org-src-mode-hook '(org-src-babel-configure-edit-buffer
org-src-mode-configure-edit-buffer)
org-agenda-before-write-hook '(org-agenda-add-entry-text)
org-babel-pre-tangle-hook '(save-buffer)
org-mode-hook '(#[0 "\300\301\302\303\304$\207"
[org-add-hook change-major-mode-hook org-show-block-all append local] 5]
#[nil
"\300\301\302\303\304$\207"
[org-add-hook change-major-mode-hook org-babel-show-result-all append local] 5]
org-babel-result-hide-spec org-babel-hide-all-hashes)
org-archive-hook '(org-attach-archive-delete-maybe)
org-ascii-format-drawer-function #[771 ".\207" [] 4 "\n\n(fn NAME CONTENTS
WIDTH)"]
org-ctrl-c-ctrl-c-hook '(org-babel-hash-at-point
org-babel-execute-safely-maybe)
org-cycle-hook '(org-cycle-hide-archived-subtrees org-cycle-hide-drawers
org-cycle-show-empty-lines
org-optimize-window-after-visibility-change)
org-archive-mark-done t
org-ditaa-eps-jar-path
"/home/malsburg/usr/share/emacs/site-lisp/contrib/scripts/DitaaEps.jar"
org-todo-keywords '((sequence "TODO" "READ" "MAYDO" "WAIT" "|" "DONE" "NODO"
"DELEGATED"))
org-babel-tangle-lang-exts '(("python" . "py") ("emacs-lisp" . "el") ("elisp"
. "el"))
org-confirm-elisp-link-function 'yes-or-no-p
org-metadown-hook '(org-babel-pop-to-session-maybe)
org-ditaa-jar-path "/home/malsburg/usr/src/org-mode/contrib/scripts/ditaa.jar"
org-html-format-headline-function 'org-html-format-headline-default-function
org-babel-load-languages '((python . t) (emacs-lisp . t) (ditaa . t) (R . t))
org-src-preserve-indentation t
org-html-format-inlinetask-function
'org-html-format-inlinetask-default-function
org-agenda-files '("/home/malsburg/Essentials/documents/all.org")
org-clock-out-hook '(org-clock-remove-empty-clock-drawer)
org-confirm-babel-evaluate nil
)
On 2016-01-31 Sun 12:08, Titus von der Malsburg wrote:
> Remember to cover the basics, that is, what you expected to happen and
> what in fact did happen. You don't know how to make a good report? See
>
> http://orgmode.org/manual/Feedback.html#Feedback
>
> Your bug report will be posted to the Org-mode mailing list.
>
>
> I used the following org-mode document:
>
> #+PROPERTY: header-args:R :tangle yes :comments org
>
> * Test
>
> Text for testing.
>
> #+BEGIN_SRC R
> message(1)
> #+END_SRC
>
> #+BEGIN_SRC R
> message(2)
> #+END_SRC
>
> When I `org-babel-tangle', this fails after the first code block is
> written. Stacktrace below. Tested with current development versions of
> Emacs and org-mode.
>
> Debugger entered--Lisp error: (error "Nothing to comment")
> signal(error ("Nothing to comment"))
> error("Nothing to comment")
> comment-region-default(1 3 nil)
> comment-region(1 3)
> #[(text) "\205&\303\230?\205& G\304V\205&\n\203
signature.asc
Description: PGP signature
Re: [O] hyperlinks stopped working
I reported the same problem a few days ago. It has already been fixed
in the development version but unfortunately the bug is still in the
version available on Elpa. I solved it by installing the development
version manually. Instructions can be found here:
http://orgmode.org/org.html#Installation
Good luck!
Titus
On 2016-01-30 Sat 19:32, Russell L. Carter wrote:
> The bug is a link like this:
>
> * [[http://google.com]]
>
> is displayed as a string literal and a link like this works:
>
> * [[ttp://google.com]]
>
> I recently started using helm, and just installed magit, but
> haven't configured it. Otherwise, the configuration has not
> changed in quite some time.
>
> Thanks,
> Russell
>
> On 01/30/16 17:03, Russell L. Carter wrote:
>> Hi,
>>
>> org-version is 8.3.3-26-ge92a06-elpa, emacs is 25.0.50.1 on FreeBSD
>> stable. Hyperlinks on my unchanged configuration just stopped
>> working, and display as the literal string. Neither
>> org-toggle-link-display nor font-lock-mode has any effect. I see
>> these in the Messages buffer:
>>
>> Error during redisplay: (jit-lock-function 1) signaled
>> (wrong-type-argument listp org-level-1)
>> Error during redisplay: (jit-lock-function 1780) signaled
>> (wrong-type-argument listp org-level-1)
>>
>> I'm using the emacs package manager. I tried deleting org and reinstalling
>> a fresh copy to no effect.
>>
>> Here's my entire configuration:
>>
>> (use-package org
>> :config
>> (setq org-directory "~")
>> (setq org-agenda-files '("~/org/TODO.org"))
>> (setq org-mobile-files '("~/org/mobile-staging-public"))
>> (setq org-mobile-directory "~/org/mobile-staging-private")
>> (setq org-mobile-inbox-for-pull "~/org/from-mobile.org")
>>
>> :mode
>> ("\\.text\\'" . org-mode)
>> ("\\.markdown\\'" . org-mode)
>> ("\\.md\\'" . org-mode))
>>
>>
>> Any clues as to what might be wrong would be appreciated.
>>
>> Thanks!
>> Russell
>>
signature.asc
Description: PGP signature
[O] Problem with org-babel-detangle
I tangeled the following org-mode file: #+BEGIN_SRC R :tangle /tmp/test.R :comments link 1 + 2 #+END_SRC #+BEGIN_SRC R :tangle /tmp/test.R :comments link 3 + 4 #+END_SRC The result was: ## [[file:test.org][No\ heading:1]] 1 + 2 ## No\ heading:1 ends here ## [[file:test.org][No\ heading:2]] 3 + 4 ## No\ heading:2 ends here Then I changes “3 + 4” to “3 + 5”, revisited the org buffer, and executed `org-babel-detangle'. Expected behavior: The second code block in org file is updated to contain “3 + 5”. Actual behaviour: I find myself in a buffer containing test.R, the cursor is inside the first code block at “1”, the second code block’s content in the org buffer is highlighted, and I have an edit buffer for that code block. The content of the second code block is not updated. No error message. Tested with a current development Emacs and the development version of org-mode. I think the culprit is `org-babel-tangle-jump-to-org'. When I call it in test.R, it does not jump to the org file as it should according to the documentation. When I call it with point on the first code block, it opens an edit buffer for the second code block in the background. When I call it with point on the second code block, it opens test.org in the background but doesn’t do anything else. Titus signature.asc Description: PGP signature
[O] Links in headings are broken
I just updated org-mode from Elpa and since then links in headings are not anymore interpreted as links. Example: * [[http://www.google.com][Google]] I’d expect to see * Google with “Google” being clickable but instead I see the complete code for the link. Links in normal text work as usual. Tested with Emacs -Q on a recent development version of Emacs. Titus signature.asc Description: PGP signature
Re: [O] Links in headings are broken
On 2016-01-26 Tue 11:35, Bruno Bigras wrote: > I think I have the same problem. Also some "TODO" keywords are now > highlighted in some headings but it could be related. I can confirm the error messages. Also, I think Bruno means that the TODO keywords are *not* highlighted. This also affects other keywords not just TODO and I can’t really see what is triggering it. I have one very large org file with hundreds of TODO items and about 10% of the TODO/DONE/… keywords are not highlighted. The non-highlighted keywords usually occur in streaks (in consecutive headings). Titus > > In the "*messages*" buffer I have: > font-lock-fontify-keywords-region: Wrong type argument: listp, > org-level-1Error during redisplay: (jit-lock-function 240) signaled > (wrong-type-argument listp org-level-1) > Error during redisplay: (jit-lock-function 1906) signaled > (wrong-type-argument listp org-level-1) > Error during redisplay: (jit-lock-function 8102) signaled > (wrong-type-argument listp org-level-1) > Error during redisplay: (jit-lock-function 9663) signaled > (wrong-type-argument listp org-level-1) > > > Le mar. 26 janv. 2016 à 14:20, Titus von der Malsburg <malsb...@posteo.de> > a écrit : > >> >> >> I just updated org-mode from Elpa and since then links in headings are >> not anymore interpreted as links. Example: >> >> * [[http://www.google.com][Google]] >> >> I’d expect to see >> >> * Google >> >> with “Google” being clickable but instead I see the complete code for >> the link. Links in normal text work as usual. >> >> Tested with Emacs -Q on a recent development version of Emacs. >> >> Titus >> >> >> -- > Bruno signature.asc Description: PGP signature
Re: [O] jabref like orgmode based solution to bibliography management (not for latex)
John’s code should do the trick. I don’t see how this could possibly cause your problems with the action menu. The change should be completely transparent for Helm. Regarding your other question: I don’t see any disadvantages of using several BibTeX files but I also don’t see an advantage because helm-bibtex gives you all you need to select your own publications with just a few key strokes. If helm-bibtex’ search does not work well in your case (perhaps another author has the same name as you), I would suggest using tags to mark your own publications: https://github.com/tmalsburg/helm-bibtex#tagging-publications Titus On 2015-12-05 Sat 05:31, John Kitchin wrote: > I cannot reproduce that, and it shouldn't have any effect. Maybe > something else is going on. > >> >> Thanks for the quick answer. this does seem to work but as a side effect >> seems to break the TAB key to select action >> the message window shows: >> >> helm-select-nth-action: Nothing is selected >> No Actions available [8 times] >> >> thx again >> >> Z >> >> On Sat, Dec 5, 2015 at 3:05 PM, John Kitchin <jkitc...@andrew.cmu.edu> >> wrote: >> >>> Try (untested) >>> >>> >>> >>> >>> >>> John >>> >>> --- >>> Professor John Kitchin >>> Doherty Hall A207F >>> Department of Chemical Engineering >>> Carnegie Mellon University >>> Pittsburgh, PA 15213 >>> 412-268-7803 >>> @johnkitchin >>> http://kitchingroup.cheme.cmu.edu >>> >>> >>> On Sat, Dec 5, 2015 at 7:17 AM, Xebar Saram <zelt...@gmail.com> wrote: >>> >>>> Hi again Titus and list >>>> >>>> so the semester is finally nearing the end which means i finally have >>>> some time (and a life :)) to get back to what i partially started a few >>>> months ago. >>>> >>>> i have a question regarding Predefined searches. i have a search that >>>> works well for searching papers i authored. >>>> i am thinking of moving towards 2 bib files instead of 1 big one, that is >>>> one for my papers and one for the rest (any disadvantages of using 2 bib >>>> files?). >>>> i want to add in the Predefined search to only draw from my file >>>> (mypaper.bib), >>>> even though in the default helm-bibtex sources it will have 2 inputs. is >>>> such a thing possible? >>>> >>>> this is how a current search i have looks like >>>> >>>> #+BEGIN_SRC emacs-lisp :results none >>>> >>>> ;; Define helm-search with predefined search expression: >>>> (defun helm-bibtex-ikloog-publications () >>>>"Search BibTeX entries authored by me" >>>>(interactive) >>>>(helm :sources '(helm-source-bibtex) >>>> :full-frame t >>>> :input "kloog !unpublished !prep " >>>> :candidate-number-limit 500)) >>>> #+END_SRC >>>> >>>> how does one add the specific .bib file filter? >>>> >>>> best >>>> >>>> Z >>>> >>>> On Sun, May 31, 2015 at 7:23 PM, Titus von der Malsburg < >>>> malsb...@posteo.de> wrote: >>>> >>>>> >>>>> On 2015-05-31 Sun 03:01, Xebar Saram wrote: >>>>> > Thanks so much everyone for these great replies. i will investigate >>>>> this >>>>> > further today and let everyone know how im going with my transition :) >>>>> > >>>>> > thanks again >>>>> > >>>>> > PS: Titus, do you think that the helm-bibtex APA style reference list >>>>> > could be user customizable in the future? >>>>> >>>>> Depends on what you mean by customizable. If you mean a customization >>>>> option to allows you to replace the function for APA formatting with >>>>> another function, then yes that would definitely make sense. >>>>> >>>>> Titus >>>>> >>>>> > >>>>> > Z. >>>>> > >>>>> > On Sat, May 30, 2015 at 6:56 PM, John Kitchin <jkitc...@andrew.cmu.edu >>>>> > >>>>> > wrote: >>>>> > >>>>> >> >>>>> >> >>>>> >> On Saturday, May 30, 2015, Titus von
Re: [O] [OFF TOPIC] almost giving up on emacs email..looking for advice?
Seconded. Mu4e is one of my favorite things in Emacs and makes a big difference in my professional life. Its search capabilities are similar to those offered by Gmail but Mu4e is faster and I don’t need to be online. I wrote helm-mu to optimize the search experience even further (gives you instant search results as you type): https://github.com/emacs-helm/helm-mu As an alternative to offlineimap, I recommend mbsync (also known as isync) which is faster and overall more mature and reliable. Titus On 2015-08-06 Thu 07:31, John Kitchin wrote: I am a happy mu4e + offlineimap user since January. Gmail is my mail server, and I also check mail by phone, tablet, sometimes browser. I run on a Mac with no issues so far. I would guess you could get a similar setup on Linux easily enough. I never got a good solution on Windows. To be fair, I have it set up to only update every 20 minutes, which I like, and I can force it to update when I want, or sometimes I switch to a browser at times where I need real-time updates. Most of the time I don't want that though! I did hack some things to get it more like the gmail experience I am accustomed to like archiving, and I did hack a function to remove myself from replies. (defun remove-kitchin-emails () Removes me from the CC list. I do not need my own emails that I send. (interactive) (message-goto-cc) (save-restriction (let ((end (point)) (start)) (beginning-of-line) (setq start (point)) (narrow-to-region start end) (mapc (lambda (email-to-remove) (beginning-of-line) (when (re-search-forward email-to-remove nil t) (replace-match ))) '(John Kitchin jkitc...@andrew.cmu.edu,? John Kitchin johnrkitc...@gmail.com,? jkitc...@cmu.edu, jkitc...@andrew.cmu.edu, johnrkitc...@gmail.com,? (message-goto-to) (when (message-field-value To) (message-goto-body))) ;; append and make local (add-hook 'mu4e-compose-mode-hook 'remove-kitchin-emails t) I also built a helm-contacts completion tool that is better than the completion I could use out of the box. Anyway, it took a while to get what I wanted, but I have hardly any complaints about it now that it works! Xebar Saram writes: Hi list I know this is a bit off topic but im desperately looking for some advice regarding email through emacs. i have tried a bunch of them over the last month (gnus, mu4e, wanderlust, rmail,mew and maybe other i forget). I had various levels of success with each one to setup (it was never easy) but i ended up sorta settling on mu4e. the problem is that mu4e never managed to work properly for me (headers were not updating when new mail arrived, reply was broken etc) so i had to give up What i want is basically pretty simple. an easy to setup email for emacs, but one that would work tightly with gmail since i do a lot of mail checking on the road via my cellphone. any advise. recommendations or setups that maybe people are willing to share? thx so much in advance Z signature.asc Description: PGP signature
Re: [O] Exporting to beamerposter
Thank you, Eric! I had to add ignoreheading to the top-level heading because the title of the poster is handled via the #+TITLE attribute, but otherwise it works nicely. It’s a little unfortunate that the wrap-all heading is needed because it doesn’t serve a purpose. I tried a couple of things to get rid of it but nothing worked because top-level elements are translated to frames and each frame starts a new page, which we don’t want on a poster. For more fancy layouts, one has to be a little creative and sprinkle the document generously with dummy headings with ignoreheadings-attribute to make the LaTeX come out correctly but I think I’m getting the hang of it. I’ll publish the poster on Gist when I’m finished. Hopefully, that will make it easier for other people to get started with posters in org. Titus On 2015-08-05 Wed 01:08, Eric S Fraga wrote: On Tuesday, 4 Aug 2015 at 22:24, Titus von der Malsburg wrote: I’d like to use org-mode to create an academic poster like this one (random example found using Google): [...] What I would like to write in org is something like the following: Beamer is fully supported in org and especially columns. The attached creates a (very boring) poster which has two columns within a single frame which is the poster. Does this do what you want? Export via C-c C-e l P signature.asc Description: PGP signature
[O] Exporting to beamerposter
I’d like to use org-mode to create an academic poster like this one
(random example found using Google):
http://robjhyndman.com/images/PosterInterests_beamer-723x1023.png
As the LaTeX target, I use beamerposter which is basically just a skin
for Beamer:
https://github.com/deselaers/latex-beamerposter
https://www.ctan.org/pkg/beamerposter?lang=en
Such a poster typically consists of two columns (or more when landscape
format is used) and blocks stacked inside these columns. Sometimes, I
also need something more fancy like a block in a column and more columns
inside that block but that’s rare.
What I would like to write in org is something like the following:
#+BEGIN_SRC org
#+BEAMER: \begin{columns}
#+BEAMER: \begin{column}{0.48\columnwidth}
* Introduction
:PROPERTIES:
:BEAMER_ENV: block
:END:
This poster is about …
* Design
:PROPERTIES:
:BEAMER_ENV: block
:END:
To test A we did B.
#+BEAMER: \end{column}
#+BEAMER: \begin{column}{0.48\columnwidth}
* Discussion
:PROPERTIES:
:BEAMER_ENV: block
:END:
Our ground-breaking results show …
#+BEAMER: \end{column}
#+BEAMER: \end{columns}
#+END_SRC
However, this doesn’t work for two reasons:
1.) Org mode ignores that I want blocks and instead uses frame
environments.
2.) The closing \end{frame} macros are misplaced, e.g:
#+BEGIN_SRC latex
…
\begin{frame}[label={sec:orgheadline3}]{Discussion}
Our ground-breaking results show …
\end{column}
\end{columns}
\end{frame}
…
#+END_SRC
My question: What do I have to do in org to get the desired structure in
Latex? This structure would be something like the following:
#+BEGIN_SRC latex
\begin{columns}
\begin{column}{0.48\columnwidth}
\begin{block}{Introduction}
This poster is about
\end{block}
\begin{block}{Design}
To test A we did B.
\end{block}
\end{column}
…
#+END_SRC
Posters really are the only type of document that has consistently
resisted being taken over by org-mode. So I would be great to have a
solution for this.
Titus
signature.asc
Description: PGP signature
Re: [O] importing and compliting contacts [WAS:email ui choices?]
On 2015-07-14 Tue 04:12, Matt Price wrote: Also, I'm wondering what the best way is to deal with contacts. Can I import my existing contacts into org-contacts? And if so, do I get tab completion in a message-mode buffer for those contacts? I wrote a little python script that reads vCard files and generates org-contacts: https://gist.github.com/tmalsburg/9747104 Titus signature.asc Description: PGP signature
Re: [O] Time-zone in dates
On 2015-07-08 Wed 09:40, Eric S Fraga wrote: On Wednesday, 8 Jul 2015 at 11:16, Russell Adams wrote: [...] Then would you store the time in UTC only, or support a full timestamp that included timezone? Finally when being displayed they can use the user's $TZ by default, and maybe a suffix of @ TZ inside the date syntax? The ideal implementation, in my opinion, would have time stamps defined stored with time zone information, as given by the user when creating them (although this could default to UTC, say, if not present in the time stamp) but displayed according to the user's $TZ (or overridden with emacs variable) in cases like agenda views. I like this proposal because it solves the problem at hand (as far as I can tell) but isn’t over-engineered. I also like that the date string that the user sees would be the string stored in the file, at least in the default case (non-agenda view). The mostly literal display of files is what sets org-mode apart from other outlines because that allows users to take full advantage of Emacs’ powerful text editing capabilities. For upwards compatibility, however, it might be best if time stamps with no time zone information be considered to be at the user's timezone, as it is now. This point is important. Whatever the solution is it should not break documents and workflows for users who don’t care about time zones. I agree that time zones are important for some people but let’s face it, org-mode made it thus far without support time zones, which suggests that it’s not that big of a deal for most users. Titus signature.asc Description: PGP signature
Re: [O] help with MWE error: Variable binding depth exceeds max-specpdl-size
I often get this error message after updating Emacs or org mode and forgetting to restart Emacs. Titus On 2015-07-03 Fri 10:12, Myles English wrote: Hello, Using the latest git HEAD (048f0), I am trying to make a MWE for another problem however, can someone please tell me what is missing from the init file because I get an error when I press TAB in the table. Starting emacs like this: $ emacs a.org -Q -l init.el with these files: a.org - * x | a | |---| | 1 | init.el --- (setq debug-on-error t) (add-to-list 'load-path ~/.emacs.d/plugins/org-mode/lisp) (add-to-list 'load-path ~/.emacs.d/plugins/org-mode/contrib/lisp t) (require 'org) ;;(require 'org-index) I get this traceback: Debugger entered--Lisp error: (error Variable binding depth exceeds max-specpdl-size) outline-on-heading-p(t) org-at-heading-p() org-element--current-element(23 element nil nil) byte-code(`\212\306\307 \211\310 P\311 \210,`)\312\211\211\211\211\211\211*+,-./\306\307 \211\310P\313 \203Teb\210\314 \210m\204L\315 /V\203\205\316\317\312\\210\202\205\320 \210\312y\210\314 \210m\204i\315 /V\203\205\316\317\321\312x\210\322 \2100\204~\323d\306\\202\203\323d\306\C\\210,\322 \210\324.\325,*$\211@-\326\f12\211;\203\263\327\31221$\202\304A\330A@21#\240\210+\2100\203\322+B+\3312;\203\351\332\3332#\202\361\334A@2\*\2113/W\204\f3/U\2053.U?\2053b)\204\211-4\204.\316\3170\203'+\202)\\210\202\211\3352;\203E\332\3332#\202M\334A@2\*\3362;\203e\332\3332#\202m\334A@2\*5\2116\203\2745\203\2746/V\204\2745/W\204\2746/U\203\232-\337\204\2745/U\203\317-\340\204\274-\341\203\3175b\210n\204\274m\204\317\316\3170\203\310+\202\312\\210\202@\342-\343\\203\344,\3452;\203\364\332\3332#\202\374\334A@2\**\2028\342-\344\\203\312,\2028\342-\346\\203!\347,\312*\2028\342-\350\\2032\351,\312*\2028\312\211,*5.6b\210*\202\211 [org-called-with-limited-levels org-outline-regexp outline-regexp org-outline-regexp-bol parent prevs t org-get-limited-outline-regexp ^ outline-next-heading nil org-before-first-heading-p org-skip-whitespace line-beginning-position throw exit org-back-to-heading \n beginning-of-line org-element-headline-parser org-element--current-element element :parent org-add-props plist-put :end get-text-property 0 plist-get :contents-begin :contents-end (plain-list table) (center-block drawer dynamic-block inlinetask property-drawer quote-block special-block) (item plain-list) eql plain-list item :structure property-drawer node-property table table-row struct trail special-flag type end origin keep-trail value ...] 10) org-element-at-point() org-table-begin(any) org-at-table\.el-p() org-element-table-parser(23 (5)) org-element--current-element(23 element nil nil) byte-code(`\212\306\307 \211\310 P\311 \210,`)\312\211\211\211\211\211\211*+,-./\306\307 \211\310P\313 \203Teb\210\314 \210m\204L\315 /V\203\205\316\317\312\\210\202\205\320 \210\312y\210\314 \210m\204i\315 /V\203\205\316\317\321\312x\210\322 \2100\204~\323d\306\\202\203\323d\306\C\\210,\322 \210\324.\325,*$\211@-\326\f12\211;\203\263\327\31221$\202\304A\330A@21#\240\210+\2100\203\322+B+\3312;\203\351\332\3332#\202\361\334A@2\*\2113/W\204\f3/U\2053.U?\2053b)\204\211-4\204.\316\3170\203'+\202)\\210\202\211\3352;\203E\332\3332#\202M\334A@2\*\3362;\203e\332\3332#\202m\334A@2\*5\2116\203\2745\203\2746/V\204\2745/W\204\2746/U\203\232-\337\204\2745/U\203\317-\340\204\274-\341\203\3175b\210n\204\274m\204\317\316\3170\203\310+\202\312\\210\202@\342-\343\\203\344,\3452;\203\364\332\3332#\202\374\334A@2\**\2028\342-\344\\203\312,\2028\342-\346\\203!\347,\312*\2028\342-\350\\2032\351,\312*\2028\312\211,*5.6b\210*\202\211 [org-called-with-limited-levels org-outline-regexp outline-regexp org-outline-regexp-bol parent prevs t org-get-limited-outline-regexp ^ outline-next-heading nil org-before-first-heading-p org-skip-whitespace line-beginning-position throw exit org-back-to-heading \n beginning-of-line org-element-headline-parser org-element--current-element element :parent org-add-props plist-put :end get-text-property 0 plist-get :contents-begin :contents-end (plain-list table) (center-block drawer dynamic-block inlinetask property-drawer quote-block special-block) (item plain-list) eql plain-list item :structure property-drawer node-property table table-row struct trail special-flag type end origin keep-trail value ...] 10) org-element-at-point() org-table-begin(any) org-at-table\.el-p() org-element-table-parser(23 (5)) org-element--current-element(23 element nil nil) byte-code(`\212\306\307 \211\310 P\311 \210,`)\312\211\211\211\211\211\211*+,-./\306\307 \211\310P\313 \203Teb\210\314 \210m\204L\315 /V\203\205\316\317\312\\210\202\205\320 \210\312y\210\314 \210m\204i\315 /V\203\205\316\317\321\312x\210\322 \2100\204~\323d\306\\202\203\323d\306\C\\210,\322
Re: [O] helm-bibtex questions
On 2015-06-26 Fri 00:21, Xebar Saram wrote: Hi Titus Another round of helm-bibtex questions if you dont mind (question come since i use it 50 times a day now ;-)) No problem. I’ve also learned a couple of things though this exchange. 1. is there a way (or a keybind) to select all entries filtered? now to select all my publications for example i have to use C-space repeatedly. Key bindings are inherited from Helm so it’s useful to consult Helm’s documentation for question of that type. I just checked and found that M-a selects all candidates. 2. what is the syntax for greater then? for example all articles 2012 (year) I’m afraid that’s not possible because 2012 is just another string for the purposes of matching. But you may want to check Helm’s documentation and mailing lists. Helm is full of surprises. 4. i cant get helm-bibtex to search the biblatex field of pubstate. are biblatex (biber) supported/ i have this in my config? (setq helm-bibtex-additional-search-fields '(pubstate)) This works on my setup. Helm-bibtex doesn’t really care whether something is a BibTeX or a Biblatex field. You should be able to use any kind of field whether standard or not. Note that additional search fields are not displayed in the results list (they are only used for matching). Perhaps that’s why you thought it doesn’t work? also on a related issue i assume one can define many fields in the above example. since my elisp sucks would the syntax be this (setq helm-bibtex-additional-search-fields '(pubstate tags)) This is correct. or do you need to qoute them or use a , symbol? 5. i love the insert formatted reference (f5) option and use it often sending people references: a. does it also auto send that to the clipboard? There is currently no way to copy references directly to the clipboard. My recommendation is to use one of Emacs’ mail clients, then you don’t need the clipboard. Mu4e is absolutely fantastic (especially when combined with helm-mu). b. it cuts most of the authors name and leaves only the first few. is there a switch to get it to print all authors. is that a latex cite formatting issue? Not sure what you mean by “cuts most of the authors”. It doesn’t cut anything in my setup. Could you please provide an example? (Perhaps this is something for the issue tracker on Github.) Best wishes, Titus best and thanks so much again Z On Mon, Jun 22, 2015 at 6:12 PM, Titus von der Malsburg malsb...@posteo.de wrote: Here is my CV in org-mode: https://gist.github.com/tmalsburg/96084ba82281937c26b7 It’s a pretty straightforward org document except for one thing: the key to making this work was biblatex which can be used to create several lists of references filtered according to keywords, author, etc. This allowed me to have separate sections for journal articles, conference presentations, etc. I store the relevant keywords in the tags field of the BibTeX entries and since biblatex doesn’t know this field, I copy the tags on-the-fly to the keywords field (see DeclareSourcemap in the LaTeX headers). Titus On 2015-06-22 Mon 07:28, Xebar Saram wrote: Hi John a bit off topic, but do you also write your academic CV in orgmode or lateX? in anycase would you mind sharing your org/latex CV template? it would be helpful as a starting point for me if thats possible. kind regards and thanks so much in advance Z On Sun, Jun 21, 2015 at 9:40 PM, John Kitchin jkitc...@andrew.cmu.edu wrote: sweet! I did not know you could do that! I will be refactoring org-ref soon to do that instead of redefining the commands! John --- Professor John Kitchin Doherty Hall A207F Department of Chemical Engineering Carnegie Mellon University Pittsburgh, PA 15213 412-268-7803 @johnkitchin http://kitchingroup.cheme.cmu.edu On Sun, Jun 21, 2015 at 2:29 PM, Titus von der Malsburg malsb...@posteo.de wrote: On 2015-06-19 Fri 03:56, Xebar Saram wrote: Hi again Titus 2 quick questions that arose from using helm-bitex today extensively: how does one exclude in the search items? for example i want to search for xebar without keyword progress (I want to exclude in progress articles not published yet) is it possible to define default enter command in helm-bibtex ? Yes. Helm uses the first action as the default action. To move an action to the top of the list you can use the following code: (helm-delete-action-from-source Insert BibTeX key helm-source-bibtex) (helm-add-action-to-source Insert BibTeX key 'helm-bibtex-insert-key helm-source-bibtex 0) The second argument in the second line is the function that executes the action. Here is a list of all actions and their functions: Open PDF file (if present): helm-bibtex-open-pdf Open URL or DOI in browser: helm-bibtex-open-url-or-doi Insert citation: helm-bibtex
Re: [O] helm-bibtex questions
On 2015-06-26 Fri 10:21, Titus von der Malsburg wrote: On 2015-06-26 Fri 00:21, Xebar Saram wrote: Hi Titus Another round of helm-bibtex questions if you dont mind (question come since i use it 50 times a day now ;-)) No problem. I’ve also learned a couple of things though this exchange. 1. is there a way (or a keybind) to select all entries filtered? now to select all my publications for example i have to use C-space repeatedly. Key bindings are inherited from Helm so it’s useful to consult Helm’s documentation for question of that type. I just checked and found that M-a selects all candidates. 2. what is the syntax for greater then? for example all articles 2012 (year) I’m afraid that’s not possible because 2012 is just another string for the purposes of matching. But you may want to check Helm’s documentation and mailing lists. Helm is full of surprises. Of course you can use regular expressions to search for a range of years: 201[2-5] Almost as good as 2012. 4. i cant get helm-bibtex to search the biblatex field of pubstate. are biblatex (biber) supported/ i have this in my config? (setq helm-bibtex-additional-search-fields '(pubstate)) This works on my setup. Helm-bibtex doesn’t really care whether something is a BibTeX or a Biblatex field. You should be able to use any kind of field whether standard or not. Note that additional search fields are not displayed in the results list (they are only used for matching). Perhaps that’s why you thought it doesn’t work? also on a related issue i assume one can define many fields in the above example. since my elisp sucks would the syntax be this (setq helm-bibtex-additional-search-fields '(pubstate tags)) This is correct. or do you need to qoute them or use a , symbol? 5. i love the insert formatted reference (f5) option and use it often sending people references: a. does it also auto send that to the clipboard? There is currently no way to copy references directly to the clipboard. My recommendation is to use one of Emacs’ mail clients, then you don’t need the clipboard. Mu4e is absolutely fantastic (especially when combined with helm-mu). b. it cuts most of the authors name and leaves only the first few. is there a switch to get it to print all authors. is that a latex cite formatting issue? Not sure what you mean by “cuts most of the authors”. It doesn’t cut anything in my setup. Could you please provide an example? (Perhaps this is something for the issue tracker on Github.) Best wishes, Titus best and thanks so much again Z On Mon, Jun 22, 2015 at 6:12 PM, Titus von der Malsburg malsb...@posteo.de wrote: Here is my CV in org-mode: https://gist.github.com/tmalsburg/96084ba82281937c26b7 It’s a pretty straightforward org document except for one thing: the key to making this work was biblatex which can be used to create several lists of references filtered according to keywords, author, etc. This allowed me to have separate sections for journal articles, conference presentations, etc. I store the relevant keywords in the tags field of the BibTeX entries and since biblatex doesn’t know this field, I copy the tags on-the-fly to the keywords field (see DeclareSourcemap in the LaTeX headers). Titus On 2015-06-22 Mon 07:28, Xebar Saram wrote: Hi John a bit off topic, but do you also write your academic CV in orgmode or lateX? in anycase would you mind sharing your org/latex CV template? it would be helpful as a starting point for me if thats possible. kind regards and thanks so much in advance Z On Sun, Jun 21, 2015 at 9:40 PM, John Kitchin jkitc...@andrew.cmu.edu wrote: sweet! I did not know you could do that! I will be refactoring org-ref soon to do that instead of redefining the commands! John --- Professor John Kitchin Doherty Hall A207F Department of Chemical Engineering Carnegie Mellon University Pittsburgh, PA 15213 412-268-7803 @johnkitchin http://kitchingroup.cheme.cmu.edu On Sun, Jun 21, 2015 at 2:29 PM, Titus von der Malsburg malsb...@posteo.de wrote: On 2015-06-19 Fri 03:56, Xebar Saram wrote: Hi again Titus 2 quick questions that arose from using helm-bitex today extensively: how does one exclude in the search items? for example i want to search for xebar without keyword progress (I want to exclude in progress articles not published yet) is it possible to define default enter command in helm-bibtex ? Yes. Helm uses the first action as the default action. To move an action to the top of the list you can use the following code: (helm-delete-action-from-source Insert BibTeX key helm-source-bibtex) (helm-add-action-to-source Insert BibTeX key 'helm-bibtex-insert-key helm-source-bibtex 0) The second argument in the second line is the function that executes the action. Here
Re: [O] helm-bibtex questions
Here is my CV in org-mode: https://gist.github.com/tmalsburg/96084ba82281937c26b7 It’s a pretty straightforward org document except for one thing: the key to making this work was biblatex which can be used to create several lists of references filtered according to keywords, author, etc. This allowed me to have separate sections for journal articles, conference presentations, etc. I store the relevant keywords in the tags field of the BibTeX entries and since biblatex doesn’t know this field, I copy the tags on-the-fly to the keywords field (see DeclareSourcemap in the LaTeX headers). Titus On 2015-06-22 Mon 07:28, Xebar Saram wrote: Hi John a bit off topic, but do you also write your academic CV in orgmode or lateX? in anycase would you mind sharing your org/latex CV template? it would be helpful as a starting point for me if thats possible. kind regards and thanks so much in advance Z On Sun, Jun 21, 2015 at 9:40 PM, John Kitchin jkitc...@andrew.cmu.edu wrote: sweet! I did not know you could do that! I will be refactoring org-ref soon to do that instead of redefining the commands! John --- Professor John Kitchin Doherty Hall A207F Department of Chemical Engineering Carnegie Mellon University Pittsburgh, PA 15213 412-268-7803 @johnkitchin http://kitchingroup.cheme.cmu.edu On Sun, Jun 21, 2015 at 2:29 PM, Titus von der Malsburg malsb...@posteo.de wrote: On 2015-06-19 Fri 03:56, Xebar Saram wrote: Hi again Titus 2 quick questions that arose from using helm-bitex today extensively: how does one exclude in the search items? for example i want to search for xebar without keyword progress (I want to exclude in progress articles not published yet) is it possible to define default enter command in helm-bibtex ? Yes. Helm uses the first action as the default action. To move an action to the top of the list you can use the following code: (helm-delete-action-from-source Insert BibTeX key helm-source-bibtex) (helm-add-action-to-source Insert BibTeX key 'helm-bibtex-insert-key helm-source-bibtex 0) The second argument in the second line is the function that executes the action. Here is a list of all actions and their functions: Open PDF file (if present): helm-bibtex-open-pdf Open URL or DOI in browser: helm-bibtex-open-url-or-doi Insert citation: helm-bibtex-insert-citation Insert reference: helm-bibtex-insert-reference Insert BibTeX key: helm-bibtex-insert-key Insert BibTeX entry: helm-bibtex-insert-bibtex Attach PDF to email: helm-bibtex-add-PDF-attachment Edit notes: helm-bibtex-edit-notes Show entry: helm-bibtex-show-entry Best, Titus best Z On Thu, Jun 18, 2015 at 9:38 PM, Titus von der Malsburg malsb...@posteo.de wrote: On 2015-06-18 Thu 04:32, Xebar Saram wrote: Hi Titus and thx so much for the answers! i will in the future use the github page to make requests. The number of matches will be displayed in the mode line. i see that now thx! :) the problem was(is) that its colored black on my black modline BG which makes it invisible ;-) i assume thats an helm config i need to change If you don’t want to type these search expressions, you could create a command that invokes helm-bibtex with a default search expression and that command could be bound to a keyboard shortcut. that would be prefect for me and a solution to my issue. would you mind giving an example of such a code chunk. unfortunately i dont know elisp though as john recommended i will do my best this summer when the semester ends to try and pick it up :) Sure, here you go: #+BEGIN_SRC elisp ;; Define helm-search with predefined search expression: (defun helm-bibtex-my-publications () Search BibTeX entries authored by Xebar Saram. (interactive) (helm :sources '(helm-source-bibtex) :full-frame t :input xebar saram :candidate-number-limit 500)) ;; Bind this search function to Ctrl-x p: (global-set-key (kbd C-x p) 'helm-bibtex-my-publications) #+END_SRC i will definitely use your tag system as you recommended, sounds perfect for me The tag system also comes in handy when generating publication lists for CVs and web pages because BibTeX does not distinguish between conference papers, posters, and talks. If you have tags for that, it’s relatively easy to create separate sections for these types of publications using biblatex or bib2bib and bibtex2html in the case of web pages. thanks again for your kind help and the amazing app ;-) You are welcome. Titus best Z On Wed, Jun 17, 2015 at 11:02 PM, Titus von der Malsburg malsb...@posteo.de wrote: On 2015-06-17 Wed 11:08, Xebar Saram wrote: Hi Titus I have been exploring helm-bibtex a bit today and have some questions
Re: [O] helm-bibtex questions
On 2015-06-19 Fri 03:56, Xebar Saram wrote: Hi again Titus 2 quick questions that arose from using helm-bitex today extensively: how does one exclude in the search items? for example i want to search for xebar without keyword progress (I want to exclude in progress articles not published yet) is it possible to define default enter command in helm-bibtex ? Yes. Helm uses the first action as the default action. To move an action to the top of the list you can use the following code: (helm-delete-action-from-source Insert BibTeX key helm-source-bibtex) (helm-add-action-to-source Insert BibTeX key 'helm-bibtex-insert-key helm-source-bibtex 0) The second argument in the second line is the function that executes the action. Here is a list of all actions and their functions: Open PDF file (if present): helm-bibtex-open-pdf Open URL or DOI in browser: helm-bibtex-open-url-or-doi Insert citation: helm-bibtex-insert-citation Insert reference: helm-bibtex-insert-reference Insert BibTeX key: helm-bibtex-insert-key Insert BibTeX entry: helm-bibtex-insert-bibtex Attach PDF to email: helm-bibtex-add-PDF-attachment Edit notes: helm-bibtex-edit-notes Show entry: helm-bibtex-show-entry Best, Titus best Z On Thu, Jun 18, 2015 at 9:38 PM, Titus von der Malsburg malsb...@posteo.de wrote: On 2015-06-18 Thu 04:32, Xebar Saram wrote: Hi Titus and thx so much for the answers! i will in the future use the github page to make requests. The number of matches will be displayed in the mode line. i see that now thx! :) the problem was(is) that its colored black on my black modline BG which makes it invisible ;-) i assume thats an helm config i need to change If you don’t want to type these search expressions, you could create a command that invokes helm-bibtex with a default search expression and that command could be bound to a keyboard shortcut. that would be prefect for me and a solution to my issue. would you mind giving an example of such a code chunk. unfortunately i dont know elisp though as john recommended i will do my best this summer when the semester ends to try and pick it up :) Sure, here you go: #+BEGIN_SRC elisp ;; Define helm-search with predefined search expression: (defun helm-bibtex-my-publications () Search BibTeX entries authored by Xebar Saram. (interactive) (helm :sources '(helm-source-bibtex) :full-frame t :input xebar saram :candidate-number-limit 500)) ;; Bind this search function to Ctrl-x p: (global-set-key (kbd C-x p) 'helm-bibtex-my-publications) #+END_SRC i will definitely use your tag system as you recommended, sounds perfect for me The tag system also comes in handy when generating publication lists for CVs and web pages because BibTeX does not distinguish between conference papers, posters, and talks. If you have tags for that, it’s relatively easy to create separate sections for these types of publications using biblatex or bib2bib and bibtex2html in the case of web pages. thanks again for your kind help and the amazing app ;-) You are welcome. Titus best Z On Wed, Jun 17, 2015 at 11:02 PM, Titus von der Malsburg malsb...@posteo.de wrote: On 2015-06-17 Wed 11:08, Xebar Saram wrote: Hi Titus I have been exploring helm-bibtex a bit today and have some questions. btw is this the preferred way to make requests/ask questions or is github preferred? Helm-bibtex is not part of org (although it tries to work well with org). So I’m not sure whether this list is the best place for discussing it. For now the issue tracker on Github might be a better option: https://github.com/tmalsburg/helm-bibtex/issues in any case i was wondering a few things: 1. is it possible to have custom sorting? i want all views to sort by Author, year, month I prefer to see the entries in the (inverse) order in which they appear in the BibTeX file. This way, recent additions show up at the top. However, I agree that sorting would be useful (see issues #5 and #21); it just doesn’t have high priority for me. Pull requests welcome. 2. i would really like a way to have stored smart groups (like the jabref dynamic groups if your aware of that). that is for example create a group that auto selects all publications i have (by my first/last name) and shows the count (in numbers) of these publications. I’m not familiar with smart groups but it seems that all helm-bibtex is doing is giving you very flexible smart groups defined by your search expressions. For example, if you want a list of your publications, you can simple enter your name. And if you want a list of your articles, you can enter your name + “article”. If you want all your articles from 2010, enter your name + “articles 2010”. And so on. The number of matches will be displayed in the mode
Re: [O] helm-bibtex questions
On 2015-06-18 Thu 04:32, Xebar Saram wrote: Hi Titus and thx so much for the answers! i will in the future use the github page to make requests. The number of matches will be displayed in the mode line. i see that now thx! :) the problem was(is) that its colored black on my black modline BG which makes it invisible ;-) i assume thats an helm config i need to change If you don’t want to type these search expressions, you could create a command that invokes helm-bibtex with a default search expression and that command could be bound to a keyboard shortcut. that would be prefect for me and a solution to my issue. would you mind giving an example of such a code chunk. unfortunately i dont know elisp though as john recommended i will do my best this summer when the semester ends to try and pick it up :) Sure, here you go: #+BEGIN_SRC elisp ;; Define helm-search with predefined search expression: (defun helm-bibtex-my-publications () Search BibTeX entries authored by Xebar Saram. (interactive) (helm :sources '(helm-source-bibtex) :full-frame t :input xebar saram :candidate-number-limit 500)) ;; Bind this search function to Ctrl-x p: (global-set-key (kbd C-x p) 'helm-bibtex-my-publications) #+END_SRC i will definitely use your tag system as you recommended, sounds perfect for me The tag system also comes in handy when generating publication lists for CVs and web pages because BibTeX does not distinguish between conference papers, posters, and talks. If you have tags for that, it’s relatively easy to create separate sections for these types of publications using biblatex or bib2bib and bibtex2html in the case of web pages. thanks again for your kind help and the amazing app ;-) You are welcome. Titus best Z On Wed, Jun 17, 2015 at 11:02 PM, Titus von der Malsburg malsb...@posteo.de wrote: On 2015-06-17 Wed 11:08, Xebar Saram wrote: Hi Titus I have been exploring helm-bibtex a bit today and have some questions. btw is this the preferred way to make requests/ask questions or is github preferred? Helm-bibtex is not part of org (although it tries to work well with org). So I’m not sure whether this list is the best place for discussing it. For now the issue tracker on Github might be a better option: https://github.com/tmalsburg/helm-bibtex/issues in any case i was wondering a few things: 1. is it possible to have custom sorting? i want all views to sort by Author, year, month I prefer to see the entries in the (inverse) order in which they appear in the BibTeX file. This way, recent additions show up at the top. However, I agree that sorting would be useful (see issues #5 and #21); it just doesn’t have high priority for me. Pull requests welcome. 2. i would really like a way to have stored smart groups (like the jabref dynamic groups if your aware of that). that is for example create a group that auto selects all publications i have (by my first/last name) and shows the count (in numbers) of these publications. I’m not familiar with smart groups but it seems that all helm-bibtex is doing is giving you very flexible smart groups defined by your search expressions. For example, if you want a list of your publications, you can simple enter your name. And if you want a list of your articles, you can enter your name + “article”. If you want all your articles from 2010, enter your name + “articles 2010”. And so on. The number of matches will be displayed in the mode line. If you don’t want to type these search expressions, you could create a command that invokes helm-bibtex with a default search expression and that command could be bound to a keyboard shortcut. Another example is a group to keep track of all the papers im working on or invloved with by matching keyword author and prep/*other key word I use two BibTeX fields to tag entries: “keywords” for keywords describing the content of the paper (as usual) and “tags” for meta data. Values that I use in tags are “own”, “manuscript”, “poster”, “talk”, … So if I want a list of all articles in progress, I search for “own manuscript”. Since the tags field is non-standard, it has to be added to `helm-bibtex-additional-search-fields`. Another solution would be to use the pubstate field and to search for your name and “forthcoming” (add pubstate to helm-bibtex-additional-search-fields for this to work). 3.is it possible to ass an option to auto generate a bibkey for a selected citation based on user criteria such as author(date)short-title? Maintaining the content of the BibTeX file not really in the scope of helm-bibtex (I prefer to write my BibTeX entries by hand). Perhaps org-ref or ebib can help here? Once you have a function that generates a new key and inserts it in the BibTeX file, you can easily add it to the list of actions in helm-bibtex. Hope that helps. Titus thx so much in advance
Re: [O] org-ref helm-bibtex notes
On 2015-06-16 Tue 18:28, Titus von der Malsburg wrote: On 2015-06-16 Tue 17:39, Julian Burgos wrote: Dear list, I have been using org-ref for a while, using reftex to insert citations in my org documents. Now I am switching to helm-bibtex, which is pretty awesome. I have a couple of question about the note files. Org-ref uses a single file to keep notes (e.g. notes.org), but helm-bibtex assumes that notes are kept in separate files, one per article. My questions are: a) Do you have a preference in the single file vs multiple files question? Are advantages/disadvantages? I tend to prefer the single file option, it makes search easy and also I can add TODO items that later I can pull out in the agenda view. With multiple files this would not be as easy. Do you agree? Hi, I’m the author of helm-bibtex. There was recently a discussion about this on Github: https://github.com/tmalsburg/helm-bibtex/issues/40 Someone convinced me that storing all notes in one file is better and there is an experimental (and incomplete) implementation in a topic branch: https://github.com/tmalsburg/helm-bibtex/tree/note-files Update: I worked on the note-files branch and as far as I’m concerned it is ready to be merged into master. There are several changes: When one big notes file is used: - The new default template for notes is simpler than what org-ref uses but it should be compatible because it uses the Custom_ID property to store the key. - Note templates can be defined in `helm-bibtex-notes-template`. - The list of publications now shows a mark if notes are available for a publication. - Finding the correct entry is now robust because the code looks for `Custom_ID: key` not just for the key. Multiple note files (one for each publication): - The template for notes is used to populate new note files. (Previously it was only used in the case with one big notes file.) Julian, if you could test this branch, that would be fantastic! Here is the code: https://github.com/tmalsburg/helm-bibtex/tree/note-files Titus (Multiple note files will still be possible for users who prefer that.) b) Helm-bibtex identifies which references have a note file, adding a symbol on the reference list. Can we make helm-bibtex look into a single file (say the notes.org file), look for the :Custom_ID: properties of the entries, and use that to mark the reference list? I am teaching myself emacs-lisp but this is above my capacity right now. Yes, something like that needs to be included. The unresolved question is how BibTeX keys should be stored in the notes file. I find property drawers incredibly clunky and in my experience they can considerably slow down Emacs in large org files (that’s the reason why I don’t use org-contacts as much as a would like). My current favorite format for entries in the notes file is the following: * Author: Title (year) :BibTeXkey: Here are the notes … The only problem I see with this is that BibTeX allows keys to contain colons, and a key with a colon would break org’s tag syntax. Suggestions welcome. Titus Many thanks, Julian signature.asc Description: PGP signature
Re: [O] helm-bibtex questions
On 2015-06-17 Wed 11:08, Xebar Saram wrote: Hi Titus I have been exploring helm-bibtex a bit today and have some questions. btw is this the preferred way to make requests/ask questions or is github preferred? Helm-bibtex is not part of org (although it tries to work well with org). So I’m not sure whether this list is the best place for discussing it. For now the issue tracker on Github might be a better option: https://github.com/tmalsburg/helm-bibtex/issues in any case i was wondering a few things: 1. is it possible to have custom sorting? i want all views to sort by Author, year, month I prefer to see the entries in the (inverse) order in which they appear in the BibTeX file. This way, recent additions show up at the top. However, I agree that sorting would be useful (see issues #5 and #21); it just doesn’t have high priority for me. Pull requests welcome. 2. i would really like a way to have stored smart groups (like the jabref dynamic groups if your aware of that). that is for example create a group that auto selects all publications i have (by my first/last name) and shows the count (in numbers) of these publications. I’m not familiar with smart groups but it seems that all helm-bibtex is doing is giving you very flexible smart groups defined by your search expressions. For example, if you want a list of your publications, you can simple enter your name. And if you want a list of your articles, you can enter your name + “article”. If you want all your articles from 2010, enter your name + “articles 2010”. And so on. The number of matches will be displayed in the mode line. If you don’t want to type these search expressions, you could create a command that invokes helm-bibtex with a default search expression and that command could be bound to a keyboard shortcut. Another example is a group to keep track of all the papers im working on or invloved with by matching keyword author and prep/*other key word I use two BibTeX fields to tag entries: “keywords” for keywords describing the content of the paper (as usual) and “tags” for meta data. Values that I use in tags are “own”, “manuscript”, “poster”, “talk”, … So if I want a list of all articles in progress, I search for “own manuscript”. Since the tags field is non-standard, it has to be added to `helm-bibtex-additional-search-fields`. Another solution would be to use the pubstate field and to search for your name and “forthcoming” (add pubstate to helm-bibtex-additional-search-fields for this to work). 3.is it possible to ass an option to auto generate a bibkey for a selected citation based on user criteria such as author(date)short-title? Maintaining the content of the BibTeX file not really in the scope of helm-bibtex (I prefer to write my BibTeX entries by hand). Perhaps org-ref or ebib can help here? Once you have a function that generates a new key and inserts it in the BibTeX file, you can easily add it to the list of actions in helm-bibtex. Hope that helps. Titus thx so much in advance, you and john have given me confidence to finally dive into the whole latex/bibteX world best Z signature.asc Description: PGP signature
Re: [O] org-ref helm-bibtex notes
On 2015-06-16 Tue 17:39, Julian Burgos wrote: Dear list, I have been using org-ref for a while, using reftex to insert citations in my org documents. Now I am switching to helm-bibtex, which is pretty awesome. I have a couple of question about the note files. Org-ref uses a single file to keep notes (e.g. notes.org), but helm-bibtex assumes that notes are kept in separate files, one per article. My questions are: a) Do you have a preference in the single file vs multiple files question? Are advantages/disadvantages? I tend to prefer the single file option, it makes search easy and also I can add TODO items that later I can pull out in the agenda view. With multiple files this would not be as easy. Do you agree? Hi, I’m the author of helm-bibtex. There was recently a discussion about this on Github: https://github.com/tmalsburg/helm-bibtex/issues/40 Someone convinced me that storing all notes in one file is better and there is an experimental (and incomplete) implementation in a topic branch: https://github.com/tmalsburg/helm-bibtex/tree/note-files (Multiple note files will still be possible for users who prefer that.) b) Helm-bibtex identifies which references have a note file, adding a symbol on the reference list. Can we make helm-bibtex look into a single file (say the notes.org file), look for the :Custom_ID: properties of the entries, and use that to mark the reference list? I am teaching myself emacs-lisp but this is above my capacity right now. Yes, something like that needs to be included. The unresolved question is how BibTeX keys should be stored in the notes file. I find property drawers incredibly clunky and in my experience they can considerably slow down Emacs in large org files (that’s the reason why I don’t use org-contacts as much as a would like). My current favorite format for entries in the notes file is the following: * Author: Title (year) :BibTeXkey: Here are the notes … The only problem I see with this is that BibTeX allows keys to contain colons, and a key with a colon would break org’s tag syntax. Suggestions welcome. Titus Many thanks, Julian signature.asc Description: PGP signature
Re: [O] Organizing and taming hectic Academia work (faculty viewpoint)? Tips or a good guides sought after :)
On 2015-06-10 Wed 07:14, Ken Mankoff wrote: I found a happy medium working in Org, exporting to LaTeX, and then using Pandoc to convert to Word. With ox-pandoc you can export to .docx directly. No need to go through LaTeX. Ox-pandoc is pretty amazing. Titus I would send the Word and always the canonical PDF version in case some equations got messed up. This requires manually incorporating the tracked changes from Word, but I've never been a fan of just clicking accept on changes anyway, and don't mind the manual re-integration of comments. -k. On 2015-06-10 at 09:49, John Kitchin jkitc...@andrew.cmu.edu wrote: Speaking as an advisor/teacher, you should do what they want if you want them to help you. You could ask if they are willing to comment on the pdf, either by hand writing on a printed version, or by pdf commenting, or maybe in the LaTeX source. But, if that is not what they want, and they cannot work with what you give them, you will not get as much feedback as you want, and you will end up creating frustration on your end and theirs. windy writes: Another question, I am a student , I think it is a big problem that how to exchange you article with your teacher, because the teacher will comment or revise your article once again and again. However, Many teachers will not use emacs to write articles and also the pdf file is not so convenient to do some modification, how will you deal with the problem ? 在2015年06月09 21时21分, John Kitchinjkitc...@andrew.cmu.edu写道: you might also enjoy our youtube video: https://www.youtube.com/watch?v=fgizHHd7nOo And this one on using org-mode in teaching: https://www.youtube.com/watch?v=IsSMs-4GlT8list=FLQp2VLAOlvq142YN3JO3y8w and https://www.youtube.com/watch?v=cRUCiF2MwP4 See http://github.com/jkitchin/jmax for my Emacs setup for org-mode. My only other advice is start learning to program in emacs-lisp. It took me about four years to get proficient enough to write org-ref. I learned by solving lots of little problems, and building up to bigger problems. A lot of those are documented in my blog. Read the emacs and emacs-lisp manuals (read them in Emacs or in a browser). They take some time, so skip the stuff that doesn't make sense and come back to it later if you need to. Consider getting the book at https://www.masteringemacs.org. It isn't about org-mode, but it will make you better at using Emacs. Consider reading Land of Lisp. It isn't about Emacs or Emacs-lisp, but it might interest you in programming in a lispy language, and it is a fun read. Buy the org-mode book: http://www.amazon.com/Org-Mode-Reference-Manual-Organize/dp/9881327709/ref=sr_1_1?ie=UTF8qid=1433855847sr=8-1keywords=org-mode. yes, it is the same stuff as in the manual, but it is a book you can read anywhere anytime. Start by learning how to get org-mode to do some things you want. Just do one thing a day. Every day. You hopefully have 30+ years of career ahead of you, so even if it takes a few years or more to learn how to program in emacs-lisp to customize your workflows, you still have plenty of time to benefit from it! Best wishes, Holger Wenzel writes: Hi Xebar, Xebar Saram zeltakc at gmail.com writes: Dear Martin Thanks so much for your prompt response. I did ofc do an extensive google research yet found that as can be seen in your link most entries focus on either writing papers or general bits an pieces .What i am looking for is a holistic approach regarding organizing all aspects of academic life and to hear workflows of other colleagues using org for that I'd start with: http://kitchingroup.cheme.cmu.edu/blog/2014/08/08/What-we-are-using-org- mode-for/ follow John Kitchin's blog there closely and read everything he posts in this list. Cheers, Holger z On Tue, Jun 9, 2015 at 12:16 AM, M Elwood151 at web.de wrote: Von: Xebar Saram zeltakc at gmail.com Datum: Mon, 8 Jun 2015 19:39:14 +0300 An: org mode emacs-orgmode at gnu.org Betreff: [O] Organizing and taming hectic Academia work (faculty viewpoint)? Tips or a good guides sought after :) Hi all Im a young assistant professor (in humanities and thus my horrific coding skills..basically non ) and having been using orgmode for a year or two now. I love orgmode dearly and use it mainly for note taking, lists etc I am aware of the fantastic orgmode capabilities that could benefit me greatly such as exporting, email tie-ins, beamer support, organizing my bibliography (i have switched to a .bib file recently for my references), agenda capabilities and so much moreand have tried several of these with mild success. unfortunately (and this maybe due to me not being very technical and lack of coding skills) i still feel like im really not using orgmode to its potential and still feel miserably lost in terms of organizing my work in academia from all aspects. i am
Re: [O] [Bug] ~Verbatim~ in headlines breaks LaTeX
On 2015-06-06 Sat 00:28, Nicolas Goaziou wrote:
Titus von der Malsburg malsb...@posteo.de writes:
Thee can be handled by protectedtexttt. The obvious questions is of
course: Wouldn’t it be more consistent to handle all instances of ~code~
using protectedtexttt?
One option would be indeed to remove \verb altogether. Note that it is
also used in inline source blocks.
However, I assume \verb put less limitations than \texttt on its
contents, so I'd rather keep \verb around.
And if you want to support the use of \verb at all, shouldn’t that be
done via =verbatim= not ~code~?
I fail to see how it would solve the problem at hand. It would simply
move it elsewhere.
I didn’t say it would. I said that using protectedtexttt solves
the issue in problematic environments.
The issue that =verbatim= maps to \texttt and ~code~ to \verb is
independent, but since it affects the same code, it might make
sense to solve both at the same time.
Titus
My question is how to handle \verb at the LaTeX level, not at the Org
one.
These two did not produce the intended results (sub and super script
don’t work) but the LaTeX is not malformed:
test^~test~
test_~test~
This really seems to be an independent issue (because test^*test*
doesn’t work either)
Actually, I just realized this is not valid syntax for sub/superscript
in Org anyway. It should be
test^{~test~}
Regards,
signature.asc
Description: PGP signature
Re: [O] [Bug] ~Verbatim~ in headlines breaks LaTeX
On 2015-05-31 Sun 01:40, Nicolas Goaziou wrote: Titus von der Malsburg malsb...@posteo.de writes: Huh, ~code~ is translated to \verb and =verbatim= is translated to \texttt (plus escaping of some special characters)? Correct. If \verb is used at all, shouldn’t it be generated by =verbatim= instead of by ~code~? Why is that? Because \verb reminds =verbatim=? Really, both code and verbatim syntax produces verbatim contents. Therefore both are eligible for \verb. Well, \verb is short for verbatim. So, yeah, it is pretty unexpected that =verbatim= is translated to testtt and ~code~ to \verb. Note that we could do better anyway and switch command depending on context. Yes, I suppose anything is better than producing malformed LaTeX. Could you give the list of all contexts requiring such a switch, and what the result should be in each case? Below is a list of things that I tested. This list of test cases is probably not exhaustive. Things that don't work with \verb (produce malformed LaTeX): #+TITLE: ~test~ #+CAPTION: ~test~ [[/tmp/img.png]] * ~test~ ** ~test~ … These two did not produce the intended results (sub and super script don’t work) but the LaTeX is not malformed: test^~test~ test_~test~ Things that did work as expected with \verb: ~test~ | ~test~ | [[http://www.fsf.org/][~test~]] - ~test~ :: this is a ~test~ [fn:1] [fn:1] ~test~ *~test~* =~test~= /~test~/ +~test~+ _~test~_ -- Dr Titus von der Malsburg Feodor Lynen Research Fellow Dept. Psychology Dept. Linguistics University of California, San Diego http://pages.ucsd.edu/~tvondermalsburg/ signature.asc Description: PGP signature
Re: [O] [Bug] ~Verbatim~ in headlines breaks LaTeX
On 2015-06-05 Fri 14:27, Nicolas Goaziou wrote:
Titus von der Malsburg malsb...@posteo.de writes:
Below is a list of things that I tested. This list of test cases is
probably not exhaustive.
Thanks.
Things that don't work with \verb (produce malformed LaTeX):
#+TITLE: ~test~
#+CAPTION: ~test~
[[/tmp/img.png]]
* ~test~
** ~test~
…
Thee can be handled by protectedtexttt. The obvious questions is of
course: Wouldn’t it be more consistent to handle all instances of ~code~
using protectedtexttt? And if you want to support the use of \verb at
all, shouldn’t that be done via =verbatim= not ~code~?
These two did not produce the intended results (sub and super script
don’t work) but the LaTeX is not malformed:
test^~test~
test_~test~
This really seems to be an independent issue (because test^*test*
doesn’t work either) but I think it should produce this LaTeX:
test\(^{\text{\texttt{test}}}\)
test\(_{\text{\texttt{test}}}\)
But this works, too:
test\(^{\text{\verb~test~}}\)
test\(_{\text{\verb~test~}}\)
Titus
signature.asc
Description: PGP signature
Re: [O] jabref like orgmode based solution to bibliography management (not for latex)
On 2015-05-31 Sun 03:01, Xebar Saram wrote: Thanks so much everyone for these great replies. i will investigate this further today and let everyone know how im going with my transition :) thanks again PS: Titus, do you think that the helm-bibtex APA style reference list could be user customizable in the future? Depends on what you mean by customizable. If you mean a customization option to allows you to replace the function for APA formatting with another function, then yes that would definitely make sense. Titus Z. On Sat, May 30, 2015 at 6:56 PM, John Kitchin jkitc...@andrew.cmu.edu wrote: On Saturday, May 30, 2015, Titus von der Malsburg malsb...@posteo.de wrote: On 2015-05-30 Sat 01:20, Xebar Saram wrote: Hi all i have been using jabref for the past 2-4 years in my academia work to manage my reference library. i dont use latex (..its on my TODO list...when (f ever) i have time..) so for now i just want something to manage my references. the key things i need to move over from jabref are: Author of helm-bibtex here. 1. easy add references Helm-bibtex doesn’t deal with this because I prefer to edit my BibTeX file by hand. BibTeX retrieved from journals is almost always messy and I need to edit it anyway. It’s not too hard, though: I click on BibTeX export on the journal page, the BibTeX file is opened in Emacs, I fix it, and use a command that appends it to my bibliography. However, I think org-ref has tools that do more to support importing new entries and org-ref combines well with helm-bibtex. Org-ref has doi-utils that let you add bibtex entries and download PDFs from a doi or crossref query. 2. a way to quick filter references (helm bibtex seems like a good solution) That’s what helm-bibtex was written to solve. 3. filter lists based on tags/keywords (orgmode has that covered) In helm-bibtex you can also search for keywords and tags. 4. this one is important: a way to quickly export selected references in word/odf/html based on a pre fixed style (ie Nature, Chicago etc) helm-bibtex can generate references in APA style but as far as I can see Chicago style is very similar, so it shouldn’t be hard to add support for that. anyone uses such a system in emacs/org and can recommend the way to go? For more details, see: https://github.com/tmalsburg/helm-bibtex Titus -- John --- Professor John Kitchin Doherty Hall A207F Department of Chemical Engineering Carnegie Mellon University Pittsburgh, PA 15213 412-268-7803 @johnkitchin http://kitchingroup.cheme.cmu.edu signature.asc Description: PGP signature
Re: [O] [Bug] ~Verbatim~ in headlines breaks LaTeX
On 2015-05-30 Sat 01:09, Nicolas Goaziou wrote: Hello, Titus von der Malsburg malsb...@posteo.de writes: Yes, I saw this thread after sending the previous email. According to `org-latex-text-markup-alist', protectedtexttt should be used, which seems like a good-enough solution for this problem. But for some reason that doesn’t happen. It happens. However, verbatim is =...= whereas ~...~ is code. The former uses protectedtexttt while the latter uses \verb. Huh, ~code~ is translated to \verb and =verbatim= is translated to \texttt (plus escaping of some special characters)? If \verb is used at all, shouldn’t it be generated by =verbatim= instead of by ~code~? Note that we could do better anyway and switch command depending on context. Yes, I suppose anything is better than producing malformed LaTeX. Titus signature.asc Description: PGP signature
Re: [O] jabref like orgmode based solution to bibliography management (not for latex)
On 2015-05-30 Sat 01:20, Xebar Saram wrote: Hi all i have been using jabref for the past 2-4 years in my academia work to manage my reference library. i dont use latex (..its on my TODO list...when (f ever) i have time..) so for now i just want something to manage my references. the key things i need to move over from jabref are: Author of helm-bibtex here. 1. easy add references Helm-bibtex doesn’t deal with this because I prefer to edit my BibTeX file by hand. BibTeX retrieved from journals is almost always messy and I need to edit it anyway. It’s not too hard, though: I click on BibTeX export on the journal page, the BibTeX file is opened in Emacs, I fix it, and use a command that appends it to my bibliography. However, I think org-ref has tools that do more to support importing new entries and org-ref combines well with helm-bibtex. 2. a way to quick filter references (helm bibtex seems like a good solution) That’s what helm-bibtex was written to solve. 3. filter lists based on tags/keywords (orgmode has that covered) In helm-bibtex you can also search for keywords and tags. 4. this one is important: a way to quickly export selected references in word/odf/html based on a pre fixed style (ie Nature, Chicago etc) helm-bibtex can generate references in APA style but as far as I can see Chicago style is very similar, so it shouldn’t be hard to add support for that. anyone uses such a system in emacs/org and can recommend the way to go? For more details, see: https://github.com/tmalsburg/helm-bibtex Titus signature.asc Description: PGP signature
Re: [O] Bug: Org export to latex produces incorrect table [8.3beta (release_8.3beta-1157-g8ddb84 @ /home/malsburg/usr/share/emacs/site-lisp/org/)]
On 2015-05-29 Fri 11:09, Charles C. Berry wrote: On Fri, 29 May 2015, Nicolas Goaziou wrote: Titus von der Malsburg malsb...@posteo.de writes: On 2015-05-24 Sun 10:09, Thomas S. Dye wrote: Titus von der Malsburg malsb...@posteo.de writes: On 2015-05-24 Sun 08:36, Thomas S. Dye wrote: Titus von der Malsburg malsb...@posteo.de writes: You got the result of rownames(x), which is expected. The table you expect is given by the following code: Ah, I see, thanks. Although the results is still somewhat unexpected. c(One:, Two:) doesn’t have rownames and colnames. So org apparently made them up when generating the table. Also expected due to :rownames yes :colnames yes. Without those two header arguments: Consider this example: #+BEGIN_SRC R :results table :exports results :colnames yes :rownames yes v - c(a, b) #+END_SRC #+RESULTS: | | x | |---+---| | 1 | a | | 2 | b | Where is the “x” coming from? In R, colnames(v) gives me NULL. rownames(v) is also NULL. You are asking Org mode to produce a table with row and column names from a vector, which lacks rows and columns. What behavior do you expect? Almost anything is better than Org showing me values that do not exist in the original data. Empty cells for row and columns names are probably the best solution because that would be faithful to the data and to the settings (:rownames yes :colnames yes). AFAICT, the x comes from R, not Org. It could also come from the way Org calls R, but I don't know enough of the latter to tell. In particular, `org-babel-R-write-object-command' contains an R function that processes the object for `:results value'. The guts of it is a call to write.table(). Here is an example: #+NAME: show write.table #+BEGIN_SRC R :results output write.table(c(a,b)) #+END_SRC #+RESULTS: show write.table : x : 1 a : 2 b The difficulty is that write.table() coerces its first argument to a `data.frame', whence the odd seeming row/column labels. Making the R code in `org-babel-R-write-object-command' smart enough to do what the OP wants without breaking stuff might be possible if anyone wants to do the work. Thanks for the pointer, Charles. If this is standard behaviour in R, I’m actually fine with it. It just wasn’t clear that write.table is used for making tables. I would add a note about this in the documentation but, correct me if I’m wrong, the whole “:results table“-thing isn’t yet described in the documentation. Is that correct? Titus However, IMO `:results output' is the way to go for such cases. There are plenty of tools in R for formatting output and the user will have better control over what is produced. signature.asc Description: PGP signature
[O] [Bug] ~Verbatim~ in headlines breaks LaTeX
#+BEGIN_EXAMPLE
* The variable ~JAVA_HOME~
…
#+END_EXAMPLE
Exporting this to LaTeX and then compiling to PDF, produces the
following error:
! Missing $ inserted.
inserted text
$
l.35 \section{The variable \verb~JAVA_HOME~}
Apparently, \verb is not allow in command arguments:
http://www.tex.ac.uk/cgi-bin/texfaq2html?label=verbwithin
One solution is uses \cprotect:
\cprotect\section{The variable \verb~JAVA_HOME~}
I don’t know how the exporter works but I wouldn’t be surprised if it
wasn’t entirely trivial to implement this.
The problem also exists in other situations where ~verbatim~ is used in
embedded contexts, for example when used in link descriptions:
[[https://encrypted.google.com/search?q=JAVA_HOME][Google
~JAVA_HOME~]]
Is there anything that speaks against using \texttt for ~verbatim~? The
HTML exporter uses the code tag for ~verbatim~ and =code=.
Titus
signature.asc
Description: PGP signature
Re: [O] [Bug] ~Verbatim~ in headlines breaks LaTeX
On 2015-05-29 Fri 21:32, Nick Dokos wrote:
Titus von der Malsburg malsb...@posteo.de writes:
#+BEGIN_EXAMPLE
* The variable ~JAVA_HOME~
#+END_EXAMPLE
Exporting this to LaTeX and then compiling to PDF, produces the
following error:
! Missing $ inserted.
inserted text
$
l.35 \section{The variable \verb~JAVA_HOME~}
Apparently, \verb is not allow in command arguments:
http://www.tex.ac.uk/cgi-bin/texfaq2html?label=verbwithin
One solution is uses \cprotect:
\cprotect\section{The variable \verb~JAVA_HOME~}
I don’t know how the exporter works but I wouldn’t be surprised if it
wasn’t entirely trivial to implement this.
The problem also exists in other situations where ~verbatim~ is used in
embedded contexts, for example when used in link descriptions:
[[https://encrypted.google.com/search?q=JAVA_HOME][Google
~JAVA_HOME~]]
Is there anything that speaks against using \texttt for ~verbatim~? The
HTML exporter uses the code tag for ~verbatim~ and =code=.
Titus
I don't know what \cprotect does but there was a discussion of this a
long time ago:
http://thread.gmane.org/gmane.emacs.orgmode/14256/focus=14257
and back then, Carsten changed it so that verbatim in headlines used
\texttt - but that was the old latex exporter: I take it things are
different now?
Yes, I saw this thread after sending the previous email. According to
`org-latex-text-markup-alist', protectedtexttt should be used, which
seems like a good-enough solution for this problem. But for some reason
that doesn’t happen.
BTW, I used the latest development versions of Emacs (-Q) and Org-mode
to test this.
Titus
signature.asc
Description: PGP signature
Re: [O] [BUG] in last org in indentation of source blocks
On 2015-05-28 Thu 11:15, Thomas S. Dye wrote: Titus von der Malsburg malsb...@posteo.de writes: I can’t reproduce the second indent but I think it’s a bug that there is any indentation at all. The documentation of `org-edit-special' (C-x ') says: Call a special editor for the element at point. … No mention of indentation or other reformatting of my code. The same goes for `org-edit-src-exit' (C-c C-c) which says: Kill current sub-editing buffer and return to source buffer. The edit-in-buffer feature should not touch the indentation. If the syntax of the language is sensitive to indentation (e.g. Python) this can break the code. Example: #+BEGIN_SRC python :results output print test #+END_SRC is invalid Python syntax. Also having one function perform two very different actions (edit code in separate buffer *and* reformat the code) is poor design. At least in this special case. When I open the code in a separate buffer but then decide not to change it (C-c C-c), I'll end up with extra indentation and this will create unnecessary changes when I commit the file in git. Does the variable org-src-preserve-indentation get the behavior you're after? It does. I propose two changes: 1.) The default value `org-src-preserve-indentation' should be t because that is safer (see Python example) and more conservative. (Don’t mess with my code!) 2.) The documentation of `org-edit-special' and `org-edit-src-exit' should point out that depending on `org-src-preserve-indentation' the code may be re-indented. Even better would be to remove `org-src-preserve-indentation' and to do the right thing, which is to leave the code untouched. Emacs already has facilities for indenting code. No need to reinvent the wheel. Titus signature.asc Description: PGP signature
Re: [O] [BUG] in last org in indentation of source blocks
On 2015-05-28 Thu 04:49, Rainer M Krug wrote: I reralised this morning that there eems to be a bug introduced in one of the last commits which causes repeted editing of source blocks to indent more each time the are edited (C-'). Original: , | #+begin_src sh | echo 2 | #+end_src ` After C-' and back again , | #+begin_src sh | echo 2 | #+end_src ` After second C-' and back , | #+begin_src sh | echo 2 | #+end_src ` When C-', the indirect buffer has the same indentation as the source block, but when switching back, two more spaces are added. I can’t reproduce the second indent but I think it’s a bug that there is any indentation at all. The documentation of `org-edit-special' (C-x ') says: Call a special editor for the element at point. … No mention of indentation or other reformatting of my code. The same goes for `org-edit-src-exit' (C-c C-c) which says: Kill current sub-editing buffer and return to source buffer. The edit-in-buffer feature should not touch the indentation. If the syntax of the language is sensitive to indentation (e.g. Python) this can break the code. Example: #+BEGIN_SRC python :results output print test #+END_SRC is invalid Python syntax. Also having one function perform two very different actions (edit code in separate buffer *and* reformat the code) is poor design. At least in this special case. When I open the code in a separate buffer but then decide not to change it (C-c C-c), I'll end up with extra indentation and this will create unnecessary changes when I commit the file in git. Titus signature.asc Description: PGP signature
Re: [O] Bug: Org export to latex produces incorrect table [8.3beta (release_8.3beta-1157-g8ddb84 @ /home/malsburg/usr/share/emacs/site-lisp/org/)]
On 2015-05-24 Sun 08:36, Thomas S. Dye wrote: Titus von der Malsburg malsb...@posteo.de writes: You got the result of rownames(x), which is expected. The table you expect is given by the following code: Ah, I see, thanks. Although the results is still somewhat unexpected. c(One:, Two:) doesn’t have rownames and colnames. So org apparently made them up when generating the table. Also expected due to :rownames yes :colnames yes. Without those two header arguments: Consider this example: #+BEGIN_SRC R :results table :exports results :colnames yes :rownames yes v - c(a, b) #+END_SRC #+RESULTS: | | x | |---+---| | 1 | a | | 2 | b | Where is the “x” coming from? In R, colnames(v) gives me NULL. #+header: :session #+BEGIN_SRC R :results table :exports results x - data.frame(a=1:2, b=3:4) rownames(x) - c(One:, Two:) #+END_SRC #+results: | One: | | Two: | hth, Tom signature.asc Description: PGP signature
Re: [O] Bug: Org export to latex produces incorrect table [8.3beta (release_8.3beta-1157-g8ddb84 @ /home/malsburg/usr/share/emacs/site-lisp/org/)]
On 2015-05-24 Sun 10:09, Thomas S. Dye wrote: Titus von der Malsburg malsb...@posteo.de writes: On 2015-05-24 Sun 08:36, Thomas S. Dye wrote: Titus von der Malsburg malsb...@posteo.de writes: You got the result of rownames(x), which is expected. The table you expect is given by the following code: Ah, I see, thanks. Although the results is still somewhat unexpected. c(One:, Two:) doesn’t have rownames and colnames. So org apparently made them up when generating the table. Also expected due to :rownames yes :colnames yes. Without those two header arguments: Consider this example: #+BEGIN_SRC R :results table :exports results :colnames yes :rownames yes v - c(a, b) #+END_SRC #+RESULTS: | | x | |---+---| | 1 | a | | 2 | b | Where is the “x” coming from? In R, colnames(v) gives me NULL. rownames(v) is also NULL. You are asking Org mode to produce a table with row and column names from a vector, which lacks rows and columns. What behavior do you expect? Almost anything is better than Org showing me values that do not exist in the original data. Empty cells for row and columns names are probably the best solution because that would be faithful to the data and to the settings (:rownames yes :colnames yes). Titus signature.asc Description: PGP signature
Re: [O] Bug: Org export to latex produces incorrect table [8.3beta (release_8.3beta-1157-g8ddb84 @ /home/malsburg/usr/share/emacs/site-lisp/org/)]
On 2015-05-24 Sun 00:01, Thomas S. Dye wrote: Titus von der Malsburg malsb...@posteo.de writes: I’m exporting the following document to LaTeX #+BEGIN_SRC R :results table :exports results :colnames yes :rownames yes x - data.frame(a=1:2, b=3:4) rownames(x) - c(One:, Two:) #+END_SRC and expect a table with the following layout: a b One: 1 3 Two: 2 4 Instead I got this: x 1 One: 2 Two: You got the result of rownames(x), which is expected. The table you expect is given by the following code: Ah, I see, thanks. Although the results is still somewhat unexpected. c(One:, Two:) doesn’t have rownames and colnames. So org apparently made them up when generating the table. Titus #+BEGIN_SRC R :results table :exports results :colnames yes :rownames yes x - data.frame(a=1:2, b=3:4) rownames(x) - c(One:, Two:) x #+END_SRC #+results: | | a | b | |--+---+---| | One: | 1 | 3 | | Two: | 2 | 4 | All the best, Tom signature.asc Description: PGP signature
[O] Bug: Org export to latex produces incorrect table [8.3beta (release_8.3beta-1157-g8ddb84 @ /home/malsburg/usr/share/emacs/site-lisp/org/)]
Remember to cover the basics, that is, what you expected to happen and
what in fact did happen. You don't know how to make a good report? See
http://orgmode.org/manual/Feedback.html#Feedback
Your bug report will be posted to the Org-mode mailing list.
I’m exporting the following document to LaTeX
#+BEGIN_SRC R :results table :exports results :colnames yes :rownames yes
x - data.frame(a=1:2, b=3:4)
rownames(x) - c(One:, Two:)
#+END_SRC
and expect a table with the following layout:
a b
One: 1 3
Two: 2 4
Instead I got this:
x
1 One:
2 Two:
Here’s the LaTeX code:
\begin{tabular}{rl}
x\\
\hline
1 One:\\
2 Two:\\
\end{tabular}
Emacs : GNU Emacs 25.0.50.5 (x86_64-unknown-linux-gnu, GTK+ Version 3.10.8)
of 2015-05-12 on montana
Package: Org-mode version 8.3beta (release_8.3beta-1157-g8ddb84 @
/home/malsburg/usr/share/emacs/site-lisp/org/)
signature.asc
Description: PGP signature
[O] org-export-dispatch not bound to C-c C-e.
`org-export-dispatch' is not anymore bound to C-c C-e. Instead C-c C-e triggers `outline-show-entry'. Seems like a bug because the documentation still says that C-c C-e should launch the export menu. Tested with git master. Titus signature.asc Description: PGP signature
Re: [O] Capturing, refiling, archiving
On 2015-05-17 Sun 01:13, Nicolas Goaziou wrote: Capture and Refile are two very different concepts. In the former, you define a static, or a set of static, accurate location that may not exist yet. In the latter, you pile up existing locations that you filter interactively, depending on the situation. I understand that. But in principle it would be possible to use the same or at least a very similar specification language for targets. But nevermind, it’s not exactly important. In your example above, it is possible to refile under any Finished headline by choosing the right path. You mean I can specify a path by typing it in when prompted by `org-refile'? Because the documentation of `org-refile-targets' doesn’t mention the possibility to specify paths as far as I can see. Archiving may indeed lack a way to specify a full path in a document. But supporting the full capture template elements doesn't make sense either. You cannot archive into a table, an item... Good point. Titus signature.asc Description: PGP signature
Re: [O] A Microsoftesque detail in org
On 2015-05-17 Sun 14:15, Rasmus wrote: Hi Jarmo, Jarmo Hurri jarmo.hu...@iki.fi writes: Rasmus ras...@gmx.us writes: With your behavior you can (i) break the TODO tag; (ii) break the cookie; (iii) break the tag. At least (i) and (ii) are quite destructive. I am not sure what you mean, since a single undo will always heal the line again, regardless of where you break it. Sure. But that seems orthogonal to the problem at hand. Re (i): Assume TODO is keyword. We don't know that TO is. Re (ii): [#B] is a cookie. [#B is not. (iii) iii :tag: is a tag :ta is not. The editor should not easily produce invalid syntax. I disagree with that last statement. I’m not aware of any Emacs mode (or any other text editor for that matter) that prevents me from producing invalid syntax. A text editor preventing invalid syntax is actually not even desirable because the path from one syntactically valid state of the document to the next often leads through invalid states. If you really want to prevent temporarily invalid documents, the result is going to be some kind of GUI application, not a text editor. While that may be a valid solution for some people, it is certainly not the Emacs way of doing things. Titus In any case it's very easy to rebind keys in a hook. If you write a org.texi patch on how to get purist keybindings we can add it. I am a BIG fan of the Org mode slogan Your life in plain text. The power of plain text has been demonstrated over and over again. You can run text manipulating commands on it, you can process it with a large array of different programming languages. Nobody is disputing that. An undo is a basic text editing feature that everyone should know. Reassigning non-standard behaviour to the return key is - in my opinion - against the ideology. I see that you use Gnus. Did you by any change use RET to open the article? It's bound to gnus-summary-scroll-up. In Emacs25, or maybe even before, RET in at least lisp mode started to indent automatically via electric-indent-mode. Are you against this? What I will agree on is that it would be better if Org used more standard mechanism and e.g. cleverly hooked newline. However, Org targets a number of versions of Emacs (ATM: 23-25), making this hard. The attached patch re-enables breaks in region four of org-complex-heading-regexp, i.e. from the cookie up to tags. A quick test suggests it works nicely. WDYT? Given enough time, I could come up with a situation where I would run a keyboard macro in which I would expect the return key to break the line, regardless of where I was on that line (in a tag or whatever). In that case there's C-o C-e or M-x newline... I am a very minor player in this game, but I would really, _really_ like Org to remain as true to it's slogan as possible. I'm still don't see this point. There's Org, the format, which should ideally be easy to use in any editor (I wrote a basic syntax parser for texworks). It's plaintext. Then there's org-mode, the principal editor of Org. It supposed to be a nice environment for composing text. —Rasmus signature.asc Description: PGP signature
Re: [O] A Microsoftesque detail in org
Hi Rasmus, just tried the patch and while I still find it weird to change the meaning of RET, this solution doesn’t get in my way as much as the previous solution did. One minor cosmetic issue: * TODO foo bar :test: When I RET between foo and bar, the tag moves to the left. I think it would be nicer if it would stay where it was. Titus On 2015-05-16 Sat 08:28, Rasmus wrote: Hi, Thanks for the comments. Nicolas Goaziou m...@nicolasgoaziou.fr writes: RET breaks headline text may be more accurate. OK. + (let* ((context (if org-return-follows-link (org-element-context) + (org-element-at-point))) +(type (org-element-type context))) +(cond + ;; At a headline + ((and (eq type 'headline) (not (bolp))) You are removing an optimization here. Checking if point is on a headline/inlinetask doesn't require to use `org-element-at-point'/`org-element-context'. It is faster to simply check for `org-outline-regexp' (or derived) at bol. This optimization is less important than it used to be, now that properties drawers are at a fixed location. Nevertheless, it might be worth keeping it in mind. I did it 'cause it's easier, I think, to read a single cond than first an if and then a cond. The latter also seems easier to fix in the future. + (org-show-entry) + (let ((string )) + (unless (and (save-excursion + (beginning-of-line) + (looking-at org-complex-heading-regexp)) +(or (and (match-beginning 3) + ( (point) +(save-excursion + (goto-char (match-beginning 4)) + (skip-chars-backward \t) + (point +(and (match-beginning 5) + (= (point) (match-beginning 5) + ;; Point is on headline keywords, tags or cookies. Do not break + ;; them: add a newline after the headline instead. + (setq string (delete-and-extract-region + (point) (or (match-beginning 5) + (line-end-position The `setq' is not necessary here. Bind it within `let' instead. You are right. + (when (match-beginning 5) + (insert (make-string (length string) ?\ ?\ - ?\s If you add this feature, please augment `test-org/return' from test-org.el accordingly. Done and and attached. Anybody against pushing this? —Rasmus signature.asc Description: PGP signature
Re: [O] A Microsoftesque detail in org
On 2015-05-16 Sat 12:00, Rasmus wrote: Hi Titus, Titus von der Malsburg malsb...@posteo.de writes: just tried the patch and while I still find it weird to change the meaning of RET, this solution doesn’t get in my way as much as the previous solution did. Try to: (with-temp-buffer (org-mode) (describe-mode)). A lot of keys have been orgified. At the extreme of the anti-org-whatever-key line of though, how would org-table work? Let me first say that I think your latest patch is a good compromise and I could totally live with that solution. Having said that, I have very mixed feelings about how org behaves in tables. I’m a heavy user of org mode and feel highly comfortable with every aspect of it. Tables are the only exception. They trip me up again and again with behavior that I perceive as counter-intuitive. The problem is that org-mode is not the only citizen in the Emacs ecosystem and therefore it matters more how the rest of Emacs behaves than how Microsoft products or other outliners behave. For instance, when I put to cursor on a headline in a markdown document and press RET, I get a newline at that position. If I put the cursor on a headline in a LaTeX document and press RET, again I get a newline. The same goes for subject lines in emails (message-mode) and many other similar situations. All these things are conceptually headlines and should therefore behave the same way. Anything else would create unnecessary cognitive load for the user. Since org-mode for many years used to behave like all the other modes that I mentioned, it is not accurate to call this position anti-org. … my 5 cents. Have a nice weekend! Titus One minor cosmetic issue: * TODO foo bar :test: When I RET between foo and bar, the tag moves to the left. I think it would be nicer if it would stay where it was. Good observation. I don't even know how to make a tab character in Emacs so I blissfully assumed them away. Anyway, this should be fixed now, though it will religiously adhere to org-tags-column which, at least for my setup, your example does not. I think this is acceptable 'cause we also need to consider the example * TODO foo \phi\delta :test: Which is pretty hard due to the overlays (display-width is two, but real length is more). Could you try this version of the patch and see if you find it more satisfactory? Thanks, Rasmus signature.asc Description: PGP signature
Re: [O] A Microsoftesque detail in org
I fully agree with this, I find this “feature” very irritating. There is a strong expectation that hitting enter inserts a line break at the position of the cursor. Can we please stick to that? When I put the cursor in the middle of a word and press enter that also “breaks” the word. Yet we would not prevent the user from doing this. Titus On 2015-05-15 Fri 02:35, Jarmo Hurri wrote: Greetings. I was just amazed by the following detail in org. In the example below, if my cursor is anywhere inside the word Example, and I press Enter, a new line will be inserted below, and the cursor will jump to the next line. The location of the cursor inside the heading line is ignored, and the heading line will not be broken. # * Example Some text. # This immediately reminded me of Microsoft products, where the software tries to be too intelligent, thus making it harder for the user. In this case, I needed to figure out that Ctrl-o is needed to break the line. I would suggest that the original interpretation of Enter would not be messed with. Messing with Alt-Enter and such is fine, but Enter, please no. Or? Jarmo signature.asc Description: PGP signature
Re: [O] Capturing, refiling, archiving
On 2015-05-13 Wed 03:40, Nicolas Goaziou wrote: Titus von der Malsburg malsb...@posteo.de writes: Capturing, refiling, and archiving all create a new entry at a target location. Yet each of these facilities has it’s own way to specify the target. Capture templates have the most powerful target specification and refiling and archiving are both fairly limited. For users that is confusing and it prevents them from getting the most out of org-mode. Is there a technical reason for why different target specifications are used or is it just historical? Wouldn’t it make sense to use just one target specification “language” and to use that everywhere? Would you mind elaborating? What, exactly, are you suggesting? The specification format used for capture templates seems to be the most expressive. I was wondering if it would make sense to use that also for refiling targets and for archiving targets. Specifically, I’d like to be able to say things like this: (setq org-refile-targets '(((file+olp my-agenda-file Agenda Finished) :prepend t) ((file+olp my-agenda-file Agenda Urgent) :prepend t))) and (setq org-archive-location '((file+olp my-agenda-file Agenda Finished) :prepend t)) The reason why I think this would be useful is that some simple things are currently not possible. Consider the following document structure: * Office ** To do ** Finished * Home ** To do ** Finished If I want to archive things under the “Agenda/Finished,” there is no way to achieve this (correct me if I’m wrong). I could try this (setq org-archive-location ::** Finished) but that is ambiguous. It doesn’t indicate which of the two “Finished” nodes should be the target. Similar problems exist for refile targets: if I want to have the first “Finished” in my targets but not the second, how would I achieve that? None of the available facilities allows me to do this (without changing the document structure). Using the capture template way of specifying targets, both problems would be easy to solve because that mechanism allows me to specify the complete path in the document tree leading to the node of interest (among other things, file+regexp, etc.) Titus signature.asc Description: PGP signature
[O] Capturing, refiling, archiving
Capturing, refiling, and archiving all create a new entry at a target location. Yet each of these facilities has it’s own way to specify the target. Capture templates have the most powerful target specification and refiling and archiving are both fairly limited. For users that is confusing and it prevents them from getting the most out of org-mode. Is there a technical reason for why different target specifications are used or is it just historical? Wouldn’t it make sense to use just one target specification “language” and to use that everywhere? Titus signature.asc Description: PGP signature
Re: [O] Inline LaTeX formulae
On 2015-05-07 Thu 13:00, Nicolas Goaziou wrote:
Titus von der Malsburg malsb...@posteo.de writes:
Rasmus’ proposal is simple and correctly implements what is specified in
the manual. Below is a patch that implements this solution. Does
anyone see a concrete problem? If not, it should be merged.
I do: you removed end of line matcher. Also, I do not see the point of
matching \s_.
Both are fixed in the patch below. I also included opening
parentheses. It’s an unlikely case but for consistency they should be
included.
You also need to update `org-latex-regexps' accordingly.
Done.
I also updated org.texi. Dashes are punctuation and don’t need special
mention. I also clarified that quotes and parentheses are considered to
be punctuation (although Emacs has separate syntax classes for them).
Thanks for your feedback.
Titus
diff --git a/doc/org.texi b/doc/org.texi
index 7b78417..d926de4 100644
--- a/doc/org.texi
+++ b/doc/org.texi
@@ -10347,9 +10347,10 @@ Text within the usual @LaTeX{} math delimiters. To
avoid conflicts with
currency specifications, single @samp{$} characters are only recognized as
math delimiters if the enclosed text contains at most two line breaks, is
directly attached to the @samp{$} characters with no whitespace in between,
-and if the closing @samp{$} is followed by whitespace, punctuation or a dash.
-For the other delimiters, there is no such restriction, so when in doubt, use
-@samp{\(...\)} as inline math delimiters.
+and if the closing @samp{$} is followed by whitespace or punctuation
+(parentheses and quotes are considered to be punctuation in this
+context). For the other delimiters, there is no such restriction, so when in
+doubt, use @samp{\(...\)} as inline math delimiters.
@end itemize
@noindent For example:
diff --git a/lisp/org-element.el b/lisp/org-element.el
index 7aab9f6..8f57c90 100644
--- a/lisp/org-element.el
+++ b/lisp/org-element.el
@@ -2963,7 +2963,7 @@ Assume point is at the beginning of the LaTeX fragment.
(search-forward $ nil t 2)
(not (memq (char-before (match-beginning 0))
'(?\s ?\t ?\n ?, ?.)))
-(looking-at \\([- \t.,?;:'\]\\|$\\))
+(looking-at
\\(\\s.\\|\\s-\\|\\s(\\|\\s)\\|\\s\\\|$\\))
(point)))
(case (char-after (1+ (point)))
(?\( (search-forward \\) nil t))
diff --git a/lisp/org.el b/lisp/org.el
index 6139876..46a73b6 100755
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -540,8 +540,8 @@ An entry can be toggled between COMMENT and normal with
'((begin ^[
\t]*\\(begin{\\([a-zA-Z0-9\\*]+\\)[^\000]+?end{\\2}\\) 1 t)
;; ($ \\([ (]\\|^\\)\\(\\(\\([$]\\)\\([^
\r\n,.$].*?\\(\n.*?\\)\\{0,5\\}[^ \r\n,.$]\\)\\4\\)\\)\\([
.,?;:'\)]\\|$\\) 2 nil)
;; \000 in the following regex is needed for org-inside-LaTeX-fragment-p
-($1 \\([^$]\\|^\\)\\(\\$[^ \r\n,;.$]\\$\\)\\([-
.,?;:'\)\000]\\|$\\) 2 nil)
-($ \\([^$]\\|^\\)\\(\\(\\$\\([^
\r\n,;.$][^$\n\r]*?\\(\n[^$\n\r]*?\\)\\{0,2\\}[^
\r\n,.$]\\)\\$\\)\\)\\([- .,?;:'\)\000]\\|$\\) 2 nil)
+($1 \\([^$]\\|^\\)\\(\\$[^
\r\n,;.$]\\$\\)\\(\\s.\\|\\s-\\|\\s(\\|\\s)\\|\\s\\\|\000\\|$\\) 2 nil)
+($ \\([^$]\\|^\\)\\(\\(\\$\\([^
\r\n,;.$][^$\n\r]*?\\(\n[^$\n\r]*?\\)\\{0,2\\}[^
\r\n,.$]\\)\\$\\)\\)\\(\\s.\\|\\s-\\|\\s(\\|\\s)\\|\\s\\\|\000\\|$\\) 2 nil)
(\\( ([^\000]*?) 0 nil)
(\\[ \\[[^\000]*?\\] 0 nil)
($$ \\$\\$[^\000]*?\\$\\$ 0 nil))
signature.asc
Description: PGP signature
Re: [O] Inline LaTeX formulae
On 2015-05-08 Fri 14:40, Nicolas Goaziou wrote:
Titus von der Malsburg malsb...@posteo.de writes:
Both are fixed in the patch below.
Thank you.
I also included opening parentheses. It’s an unlikely case but for
consistency they should be included.
If there's no need to exclude opening parenthesis, I suggest to use
\\([[:punct:][:space:]]\\|$\\)
This looks indeed much nicer but it’s not what we want. The Emacs
documentation says:
‘[:punct:]’
This matches any punctuation character. (At present, for multibyte
characters, it matches anything that has non-word syntax.)
If this matches any non-word multibyte character, it also matches things
like the multiplication sign along with a lot of other non-punctuation
characters. So if we’d use [:punct:] we would incorrectly detect a
latex fragment in the following example:
50$=10$×5
The patch with commit message is below. I did the FSF copyright
paperwork a while ago (for a contribution to Emacs) so the TINYCHANGE
tag may not be required.
instead of
\\(\\s.\\|\\s-\\|\\s(\\|\\s)\\|\\s\\\|$\\)
It is shorter and clearer.
I also updated org.texi. Dashes are punctuation and don’t need special
mention. I also clarified that quotes and parentheses are considered to
be punctuation (although Emacs has separate syntax classes for them).
OK.
Could you provide a commit message for this patch and send it again,
with change above?
Fix detection of latex fragments
* org-element.el (org-element-latex-fragment-parser):
* org.el (org-latex-regexps): Fix the detection of latex
fragments. Uses syntax tables to detect whitespaces and punctuation
marks following the final $ sign.
In order to qualify as a math delimiter, the final $ sign of a LaTeX
fragment has to be followed by a whitespace or punctuation mark but the
regexp used in the previous code matched only a small number of
punctuation marks and therefore missed some latex fragments.
diff --git a/doc/org.texi b/doc/org.texi
index 7b78417..d926de4 100644
--- a/doc/org.texi
+++ b/doc/org.texi
@@ -10347,9 +10347,10 @@ Text within the usual @LaTeX{} math delimiters. To
avoid conflicts with
currency specifications, single @samp{$} characters are only recognized as
math delimiters if the enclosed text contains at most two line breaks, is
directly attached to the @samp{$} characters with no whitespace in between,
-and if the closing @samp{$} is followed by whitespace, punctuation or a dash.
-For the other delimiters, there is no such restriction, so when in doubt, use
-@samp{\(...\)} as inline math delimiters.
+and if the closing @samp{$} is followed by whitespace or punctuation
+(parentheses and quotes are considered to be punctuation in this
+context). For the other delimiters, there is no such restriction, so when in
+doubt, use @samp{\(...\)} as inline math delimiters.
@end itemize
@noindent For example:
diff --git a/lisp/org-element.el b/lisp/org-element.el
index 7aab9f6..8f57c90 100644
--- a/lisp/org-element.el
+++ b/lisp/org-element.el
@@ -2963,7 +2963,7 @@ Assume point is at the beginning of the LaTeX fragment.
(search-forward $ nil t 2)
(not (memq (char-before (match-beginning 0))
'(?\s ?\t ?\n ?, ?.)))
-(looking-at \\([- \t.,?;:'\]\\|$\\))
+(looking-at
\\(\\s.\\|\\s-\\|\\s(\\|\\s)\\|\\s\\\|$\\))
(point)))
(case (char-after (1+ (point)))
(?\( (search-forward \\) nil t))
diff --git a/lisp/org.el b/lisp/org.el
index 6139876..46a73b6 100755
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -540,8 +540,8 @@ An entry can be toggled between COMMENT and normal with
'((begin ^[
\t]*\\(begin{\\([a-zA-Z0-9\\*]+\\)[^\000]+?end{\\2}\\) 1 t)
;; ($ \\([ (]\\|^\\)\\(\\(\\([$]\\)\\([^
\r\n,.$].*?\\(\n.*?\\)\\{0,5\\}[^ \r\n,.$]\\)\\4\\)\\)\\([
.,?;:'\)]\\|$\\) 2 nil)
;; \000 in the following regex is needed for org-inside-LaTeX-fragment-p
-($1 \\([^$]\\|^\\)\\(\\$[^ \r\n,;.$]\\$\\)\\([-
.,?;:'\)\000]\\|$\\) 2 nil)
-($ \\([^$]\\|^\\)\\(\\(\\$\\([^
\r\n,;.$][^$\n\r]*?\\(\n[^$\n\r]*?\\)\\{0,2\\}[^
\r\n,.$]\\)\\$\\)\\)\\([- .,?;:'\)\000]\\|$\\) 2 nil)
+($1 \\([^$]\\|^\\)\\(\\$[^
\r\n,;.$]\\$\\)\\(\\s.\\|\\s-\\|\\s(\\|\\s)\\|\\s\\\|\000\\|$\\) 2 nil)
+($ \\([^$]\\|^\\)\\(\\(\\$\\([^
\r\n,;.$][^$\n\r]*?\\(\n[^$\n\r]*?\\)\\{0,2\\}[^
\r\n,.$]\\)\\$\\)\\)\\(\\s.\\|\\s-\\|\\s(\\|\\s)\\|\\s\\\|\000\\|$\\) 2 nil)
(\\( ([^\000]*?) 0 nil)
(\\[ \\[[^\000]*?\\] 0 nil)
($$ \\$\\$[^\000]*?\\$\\$ 0 nil))
signature.asc
Description: PGP signature
Re: [O] Inline LaTeX formulae
On 2015-05-07 Thu 00:42, Eric S Fraga wrote: On Wednesday, 6 May 2015 at 13:35, Titus von der Malsburg wrote: [...] So if the problem is only due to mistaken optimization, it would perhaps be best to just revert to the previous code. Or if the optimisation was key to getting acceptable performance, maybe discourage the use of $...$ and emphasise the use of \(...\). The latter is less fragile and is easy to generate by typing $ using the following function and binding: #+begin_src emacs-lisp ;; from Nicolas Richard theonewiththeevill...@yahoo.fr ;; Date: Fri, 8 Mar 2013 16:23:02 +0100 ;; Message-ID: 87vc913oh5@yahoo.fr (defun yf/org-electric-dollar nil When called once, insert \\(\\) and leave point in between. When called twice, replace the previously inserted \\(\\) by one $. (interactive) (if (and (looking-at )) (looking-back ()) (progn (delete-char 2) (delete-char -2) (insert $)) (insert \\(\\)) (backward-char 2))) (define-key org-mode-map (kbd $) 'yf/org-electric-dollar) #+end_src The problem with $ in org mode is that it is a valid standalone character (i.e. currency symbol). Having it perform two functions (symbol and LaTeX directive) makes it difficult to optimise performance. The double use of the $ character makes things somewhat tricky, true. However, the org manual makes it perfectly clear how the $ sign should be interpreted and earlier versions of org implemented that specification. Hence, there is no need to reeducate users about how they should write inline formulas. This is simply a bug and it should be fixed. Rasmus’ proposal is simple and correctly implements what is specified in the manual. Below is a patch that implements this solution. Does anyone see a concrete problem? If not, it should be merged. Titus org-element: Ensure correct detection of latex fragments * org-element.el (org-element-latex-fragment-parser): Ensure correct detection of latex fragments in `org-element-latex-fragment-parser'. Uses syntax tables to detect whitespaces and punctuation marks following the final $ sign. In order to qualify as a math delimiter, the final $ sign of a LaTeX fragment has to be followed by a whitespace or punctuation mark but the regexp used in the previous code matched only a small number of punctuation marks and therefore missed some latex fragments. diff --git a/lisp/org-element.el b/lisp/org-element.el index 7aab9f6..d0c0485 100644 --- a/lisp/org-element.el +++ b/lisp/org-element.el @@ -2963,7 +2963,7 @@ Assume point is at the beginning of the LaTeX fragment. (search-forward $ nil t 2) (not (memq (char-before (match-beginning 0)) '(?\s ?\t ?\n ?, ?.))) -(looking-at \\([- \t.,?;:'\]\\|$\\)) +(looking-at \\(\\s.\\|\\s-\\|\\s)\\|\\s\\\|\\s_\\)) (point))) (case (char-after (1+ (point))) (?\( (search-forward \\) nil t)) signature.asc Description: PGP signature
Re: [O] Inline LaTeX formulae
On 2015-05-06 Wed 03:24, Rasmus wrote: Hi Titus, Titus von der Malsburg malsb...@posteo.de writes: Parentheses are punctuation, so the $ in my example should be interpreted as math delimiters. I think whoever wrote the code, simply overlooked parentheses when implementing the punctuation part. I believe the problem is complicated. I had a look at the code in org-element.el (thanks for the pointer). There is clearly a bigger problem here: There is a regexp listing all characters that must follow the final $ to make it qualify as a math delimiter (whitespace, punctuation). As I suspected, the parentheses are missing from that list (and adding them solves my problem). However, a metric ton of other punctuation marks are missing as well, Spanish question marks, curly/smart quotes, real dashes (a minus is not a dash!), …, even the exclamation mark is missing. If syntax tables allow a proper solution, great. I understand that syntax tables have a different meaning in different modes but does that matter? We’re only concerned about org-mode, right? Are there scenarios where the org parser is used in a non-org-mode buffer? I also saw that the commit that introduced the problem had the following description: Avoid using slow regexp. So if the problem is only due to mistaken optimization, it would perhaps be best to just revert to the previous code. Titus In principal you could change the regexp in org-element-latex-fragment-parser to something like \\(\\s.\\|\\s-\\|\\s)\\|\\s\\\|\\s_\\) You'd only be relying on syntax tables, which I believe is what you are suggesting. But this is also dangerous, see e.g. the recent change of org-string-nw-p which previously relied on \\S cf.: http://article.gmane.org/gmane.emacs.orgmode/95473 This should be fixed. Patches welcome. You could try to submit a patch where you add closing parenthesis characters. It could even be patches to org.texi! Thanks, Rasmus signature.asc Description: PGP signature
[O] Inline LaTeX formulae
Hi all, I just updated to the development version of org and encountered a problem with inline LaTeX formulae. I have the following test document: #+OPTIONS: toc:nil tex:t Test: ($p\ll.001$) Before the update the output used to be (export to PDF via pdflatex): Test: p⋘.001 (The symbold after the p is “much less than“, hope that comes out.) Now I get: Test: ($p⋘.001$) In the .tex file, it looks like this: Test: (\$p\(\ll\).001\$) Playing with the tex variable in the options doesn’t help: for tex:nil and tex:verbatim, I get the same output. Interestingly, when I remove the parentheses, it works again. Seems like a bug where inline LaTeX is not recognized when it occurs in parentheses. Is there a quick fix for that? Titus signature.asc Description: PGP signature
Re: [O] Inline LaTeX formulae
Rasums wrote: Titus von der Malsburg malsburg at posteo.de writes: Hi all, I just updated to the development version of org and encountered a problem with inline LaTeX formulae. I have the following test document: #+OPTIONS: toc:nil tex:t Test: ($p\ll.001$) Try: Test: (\(p\ll.001\)) ($x$) doesn't work. You could use $(x)$. Strangely org-highlight-latex-and-related still highlights it. –Rasmus Thanks, Rasmus (and Marcin), replacing the $ by \( and \) works. I didn’t know about the parentheses notation. To my experience most people use the $ notation for inline math, and therefore it would make sense to properly support that notation, too. Especially since it used to work in earlier versions of org (if I’m not mistaken) and there is nothing in the manual suggesting that it shouldn’t work. The contrary is the case. Quote from the manual: To avoid conflicts with currency specifications, single ‘$’ characters are only recognized as math delimiters if the enclosed text contains at most two line breaks, is directly attached to the ‘$’ characters with no whitespace in between, and if the closing ‘$’ is followed by whitespace, punctuation or a dash. Parentheses are punctuation, so the $ in my example should be interpreted as math delimiters. I think whoever wrote the code, simply overlooked parentheses when implementing the punctuation part. This should be fixed. Titus signature.asc Description: PGP signature
Re: [O] Include HTML fragments in HTML export
Thanks Ramus and Giuseppe, as you say it works as expected in v8.3beta. Titus On 2015-03-19 Thu 01:28, Giuseppe Lipari wrote: Hi, I have a similar setting, and it works fine for me: #+INCLUDE: ./all_pub.html html (notice the absence of around the file name) I use org-8.3beta (taken from the git repo some weeks ago). Best, Giuseppe Lipari 2015-03-18 19:46 GMT+01:00 Rasmus ras...@gmx.us: Hi, Titus von der Malsburg malsb...@posteo.de writes: * My personal home page ** Articles #+INCLUDE file1.html html ** Posters #+INCLUDE file2.html html This works in Org 8.3. Org 8.2 does not seem to insert blocks cf. org-export-expand-include-keyword. Hope it helps, Rasmus -- Me gusta la noche, me gustas tú signature.asc Description: PGP signature
[O] Include HTML fragments in HTML export
Hi list, I use org mode to create my personal webpage via the HTML exporter. Some parts of my webpage are automatically generated (using bibtex2html) and stored as HTML fragments in separate files. I'd like to include the content of these files in the resulting document but there seems to be no way to achive this. One approach I tried is the following: * My personal home page ** Articles #+INCLUDE file1.html html ** Posters #+INCLUDE file2.html html This, however, escapes the HTML from file1.html and file2.html and I see the HTML source in the resulting webpage not the rendered version. Is this a bug in the HTML exporter or is this the intended behavior? If this behavior is intended, how can I include unescaped HTML in the output of the HTML export? Titus signature.asc Description: PGP signature
[O] Basic vcard-to-org-contacts converter
Hi list! I decided to give org-contacts a try. Since there doesn't seem to be a facility for importing contacts in vcard format, I wrote a little Python script for that. Perhaps someone on this list finds it useful. https://gist.github.com/tmalsburg/9747104 The script uses the Python package vobject for parsing vcard files. On Debian-like systems this package is available as python-vobject. I tested the script with contacts exported from Apple's iCloud service and that worked well. However, the vcard format is somewhat messy and I don't know what happens with vcard files generated in other contact managers. Use at your own risk. If there's interest, I might migrate the script to a proper Github repository and develop it further, i.e., merge your pull-requests ;-) Titus
