Re: CSL-JSON support for =parsebib=

2021-05-07 Thread Titus von der Malsburg


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=

2021-05-07 Thread Titus von der Malsburg


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=

2021-05-07 Thread Titus von der Malsburg



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

2020-11-30 Thread Titus von der Malsburg


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

2020-11-30 Thread Titus von der Malsburg


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

2020-11-30 Thread Titus von der Malsburg


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

2020-11-30 Thread Titus von der Malsburg


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

2020-11-23 Thread Titus von der Malsburg


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'

2020-11-16 Thread Titus von der Malsburg

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

2020-11-12 Thread Titus von der Malsburg

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

2020-11-10 Thread Titus von der Malsburg


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

2020-11-09 Thread Titus von der Malsburg


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

2020-11-06 Thread Titus von der Malsburg

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

2020-11-03 Thread Titus von der Malsburg

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.

2017-05-21 Thread Titus von der Malsburg

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

2017-05-21 Thread Titus von der Malsburg

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

2017-02-10 Thread Titus von der Malsburg

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

2017-02-06 Thread Titus von der Malsburg

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

2017-02-03 Thread Titus von der Malsburg

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

2017-02-03 Thread Titus von der Malsburg


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

2017-02-02 Thread Titus von der Malsburg

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

2017-02-02 Thread Titus von der Malsburg

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

2017-02-02 Thread Titus von der Malsburg

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

2016-02-02 Thread Titus von der Malsburg

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

2016-02-01 Thread Titus von der Malsburg

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/)]

2016-01-31 Thread Titus von der Malsburg

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

2016-01-31 Thread Titus von der Malsburg

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/)]

2016-01-31 Thread Titus von der Malsburg
;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

2016-01-30 Thread Titus von der Malsburg

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

2016-01-29 Thread Titus von der Malsburg

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

2016-01-26 Thread Titus von der Malsburg


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

2016-01-26 Thread Titus von der Malsburg

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)

2015-12-05 Thread Titus von der Malsburg

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?

2015-08-06 Thread Titus von der Malsburg

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

2015-08-05 Thread Titus von der Malsburg

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

2015-08-04 Thread Titus von der Malsburg

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?]

2015-07-14 Thread Titus von der Malsburg

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

2015-07-08 Thread Titus von der Malsburg

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

2015-07-03 Thread Titus von der Malsburg

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

2015-06-26 Thread Titus von der Malsburg

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

2015-06-26 Thread Titus von der Malsburg

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

2015-06-22 Thread Titus von der Malsburg


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

2015-06-21 Thread Titus von der Malsburg

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

2015-06-18 Thread Titus von der Malsburg

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

2015-06-17 Thread Titus von der Malsburg


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

2015-06-17 Thread Titus von der Malsburg

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

2015-06-16 Thread Titus von der Malsburg

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 :)

2015-06-10 Thread Titus von der Malsburg

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

2015-06-06 Thread Titus von der Malsburg

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

2015-06-05 Thread Titus von der Malsburg

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

2015-06-05 Thread Titus von der Malsburg

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)

2015-05-31 Thread Titus von der Malsburg

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

2015-05-30 Thread Titus von der Malsburg

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)

2015-05-30 Thread Titus von der Malsburg

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/)]

2015-05-29 Thread Titus von der Malsburg

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

2015-05-29 Thread Titus von der Malsburg


#+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

2015-05-29 Thread Titus von der Malsburg

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

2015-05-28 Thread Titus von der Malsburg

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

2015-05-28 Thread Titus von der Malsburg

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/)]

2015-05-24 Thread Titus von der Malsburg

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/)]

2015-05-24 Thread Titus von der Malsburg

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/)]

2015-05-24 Thread Titus von der Malsburg

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/)]

2015-05-23 Thread Titus von der Malsburg

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.

2015-05-18 Thread Titus von der Malsburg

`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

2015-05-17 Thread Titus von der Malsburg

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

2015-05-17 Thread Titus von der Malsburg

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

2015-05-16 Thread Titus von der Malsburg

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

2015-05-16 Thread Titus von der Malsburg

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

2015-05-15 Thread Titus von der Malsburg


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

2015-05-13 Thread Titus von der Malsburg

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

2015-05-12 Thread Titus von der Malsburg

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

2015-05-08 Thread Titus von der Malsburg

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

2015-05-08 Thread Titus von der Malsburg

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

2015-05-07 Thread Titus von der Malsburg

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

2015-05-06 Thread Titus von der Malsburg

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

2015-05-05 Thread Titus von der Malsburg


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

2015-05-05 Thread Titus von der Malsburg

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

2015-03-19 Thread Titus von der Malsburg

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

2015-03-18 Thread Titus von der Malsburg

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

2014-03-24 Thread Titus von der Malsburg

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