Re: [O] [ Bug] tsia-{up, down} sorting strategy not working for tags search agendas

[Sebastien Vauban]

Subhan Michael Tindall wrote:
> I have the following agendas (among others) defined:
> ("x" "Last worked" ((alltodo "" ( (org-agenda-sticky nil)
> (org-agenda-sorting-strategy (quote (tsia-up 
> todo-state-down)))
> ("y" "Last worked2" ((tags "LastWorked={.+}" (
> (org-agenda-sticky nil)
> (org-agenda-sorting-strategy (quote (tsia-up 
> todo-state-down)))
>
> I have a property defined in headlines that have been worked on:
> :PROPERTIES:
> :LastWorked: [2014-09-02 Tue 16:02]
> :END:
>
> TODOs etc that have not been worked yet don't have this property.
>
> The top search ("x") creates an agenda with items with a LastWorked property
> sorted with the least recent first, down to most recent, followed by any items
> with the LastWorked property unset sorted by todo-state.
>
> The bottom search ("y") creates an agenda with only items with LastWorked
> property set (which I want) but completely ignores the tsia-up sorting 
> strategy
> and sorts only by todo-state.
>
> I have confirmed that org-agenda-sorting-strategy-selected is correct in both 
> cases.
> The only difference is the agenda type (tags vs alltodo)
>
> Any ideas where to look for this ?

I guess it's directly linked to a problem I reported last
September. This is indeed annoying...

See issue #29 on http://orgmode.org/worg/org-issues.html (and see the
pointed thread).

Best regards,
  Seb

-- 
Sebastien Vauban

Re: [O] [Bug?] Results of code block printed in wrong place

[Tobias Getzner]

Hello Nicolas,

On Mo, 2014-09-22 at 17:29 +0200, Nicolas Goaziou wrote:
> FWIW, I cannot reproduce it.

This was quite painful to isolate, but I’ve now identified a minimal
configuration which should trigger this bug.

──
;; BEGIN minimal.el
(add-to-list 'load-path (expand-file-name "~/.emacs.d/elpa/org-20140922"))

;; Example needs sh; might also trigger with other langs.
(org-babel-do-load-languages
  'org-babel-load-languages
  '((sh .t)))

(fset 'yes-or-no-p 'y-or-n-p)

(defun my-org-mode-hook ()
   (follow-mode))
(add-hook 'org-mode-hook 'my-org-mode-hook)
;; END minimal.el
──

This seems rather bizarre. Both follow-mode and the y-or-n-p alias work
in isolation, but when both are used at the same time, I observe the
bug initially described. Can you confirm this?

Best regards,
Tobias

Re: [O] autosave in org-src buffer only works ones

[Adriaan Sticker]

Hi, is it possible that these function cause the buffer automatically
scrolling when saving?
When I save My buffer jumps/scrolls up so that my cursor is on the last row
on my screen.

Greets

2014-09-11 23:55 GMT+02:00 Adriaan Sticker :

> Cool, thanks!
>
> 2014-09-11 18:28 GMT+02:00 Nicolas Goaziou :
>
>> Hello,
>>
>> Adriaan Sticker  writes:
>>
>> > I've the following in my init.el
>> >
>> > (setq org-edit-src-auto-save-idle-delay 5)
>> >
>> > If I open in my org file a R code block with C-c ', edit into the opened
>> > org-src buffer with the ESS major mode activated and wait for 5s, I can
>> see
>> > autosave kicking in and my org buffer gets updated with my new code. But
>> > when I keep editing it doesn't save anymore. So it only save ones after
>> the
>> > first 5s when the org-src got openend and then it stops.
>>
>> This should now be fixed. Thank you for reporting it.
>>
>>
>> Regards,
>>
>> --
>> Nicolas Goaziou
>>
>
>

Re: [O] Struggling with new exporter

[Phillip Lord]

Nicolas Goaziou  writes:

> [...]
>
> `org-html-publish-to-html' is not meant to be called directly, but
> rather used in a project definition as a :publishing-function value.
>
> Speaking of which, why don't you simply create a proper project-alist
> and call `org-publish' on it (interactively or not)?


Okay, I've done it this way. Took a bit of fiddling since I need the
project-alist to work in different configurations (i.e. interactively,
in batch and in batch on a CI machine). Also, the timestamp stuff
confused me -- org was skipping publication, even though the output file
had been deleted.

This part...

#+BIND: org-latex-custom-lang-environments ((clojure "tawny"))
#+BIND: org-latex-listings t

isn't working at the moment. Source listings are coming out in verbatim.
Can I set this in the project-alist. From looking at org-latex-src-block
it would appear not.

Phil

Re: [O] CV in orgmode for export to pdf (and html?

[Rasmus]

Rainer M Krug  writes:

Thanks for the summary Rainer.

> I think that org could be a perfect environment for building CVs if
> one could come up with an HOWTO and many examples how to do it - and I
> think this is going into the right direction.

I think the "right" approach is cooking up a reasonable way to
represent CVs and make an ox-cv with a customized interface (like
ox-koma-letter where ordering of blocks can also be changed
"on-the-go") and provide some nice default "themes".  It should either
build on an established LaTeX cv package or just KOMA-Script like
Xavier's CV (and mine).  I didn't check the ox-cv.el that was posted
carefully.

That being said, I don't have much time for this right now.

It would be nicer to handle something like a CV in org than LaTeX.

Cheers,
Rasmus

-- 
Evidence suggests Snowden used a powerful tool called monospaced fonts

Re: [O] Bug: LaTeX export produces no output; clobbering keybindings [8.2.7c(8.2.7c-64-g01f736-elpa@/home/tbg/.emacs.d/elpa/org-20140915/)]

[Tobias Getzner]

On Wed, 17 Sep 2014 09:29:48 +, Tobias Getzner wrote:

> On Wed, 17 Sep 2014 08:27:21 +, Tobias Getzner wrote:
> 
>> When using LaTeX-based export targets that produce a .tex file as output
>> (export to LaTeX file, PDF, PDF and open), I receive the message «Buffer
>> foo.tex modified; kill anyway?». Irrespective of whether I answer y/n,
>> no .tex file is produced, and «latexmk» fails with «no such file».
>> 
>> Both after issuing the file-producing exports, and when issuing
>> exports to buffer only (export to LaTeX buffer), the keybindings in the
>> original org-mode buffer become garbled; e. g., issuing another «C-c
>> C-e» after attempting a LaTeX export no longer invokes the export menu,
>> but is now bound to the command «LaTeX-enviroment». 
> 
> I seem to have located the trigger. Inter alia, my TeX-mode-hook invokes 
> «(TeX-source-correlate-mode)» which sets a variable so that synctex files 
> are generated when running AucTeX commands. When this command is removed, 
> exporting to .tex files appears to work again and the keybindings remain 
> unchanged after export. Is this a bug, or is some configuration required 
> to make org-mode not trip over the TeX-mode hook?

This behavior seems to be related to [1] in that it only triggers when
follow-mode is used. I’ve noticed I can keep my TeX-mode-hook unchanged if
I disable follow-mode. I contrast to [1], no interaction with aliasing
yes-or-no-p to y-or-n-p seemed to be present, though.

[1] http://article.gmane.org/gmane.emacs.orgmode/91006

Re: [O] CV in orgmode for export to pdf (and html?

[Rainer M Krug]

Rasmus  writes:

> Hi,
>
> Rainer M Krug  writes:
>
> Thanks for the summary Rainer.

Hope I didn't forget anything...

>
>> I think that org could be a perfect environment for building CVs if
>> one could come up with an HOWTO and many examples how to do it - and I
>> think this is going into the right direction.
>
> I think the "right" approach is cooking up a reasonable way to
> represent CVs and make an ox-cv with a customized interface (like
> ox-koma-letter where ordering of blocks can also be changed
> "on-the-go") and provide some nice default "themes".  It should either
> build on an established LaTeX cv package or just KOMA-Script like
> Xavier's CV (and mine).  I didn't check the ox-cv.el that was posted
> carefully.

Yes - this might be the most "org-ish" approach, and the most stable
(over time).

>
> That being said, I don't have much time for this right now.

Isn't there a worg / org page, where these ideas are collected (TODO?
Feature Requests, ...)? I fear that this becomes forgotten again
(including myself!), as CVs are not something one uses regularly...

I unfortunately have not the elisp knowledge to contribute much here.

>
> It would be nicer to handle something like a CV in org than LaTeX.

I completely agree with you - I have it at the moment in LyX, but I am
fixing issues each time I need a CV.

Cheers,

Rainer

>
> Cheers,
> Rasmus

-- 
Rainer M. Krug

PGP: 0x0F52F982


pgpy7v8eB7geD.pgp
Description: PGP signature

Re: [O] [bug?] org-copy-face doesn’t add faces to org-faces customize group

[Sebastien Vauban]

Hi Aaron,

Aaron Ecay wrote:
> 2014ko abuztuak 29an, Sebastien Vauban-ek idatzi zuen:
>> I think it's related to an Emacs bug (#16440) which I reported on the
>> Org mailing list in February.
>
> I don’t completely understand what is going on in that bug report.  My
> proposal is to convert org-copy-face to defface.

I think this is "the right thing" (TM).

> I can’t tell if this would fix your problem or not, but if it’s
> exclusive to the faces I listed in my previous email the answer is
> probably “yes.”

>From what I can see, yes, the faces which are wrongly displayed (before
re-applying the theme) match the ones defined by `org-copy-face'.  So,
this seems the right way to go.

Best regards,
  Seb

-- 
Sebastien Vauban

Re: [O] [Bug?] Results of code block printed in wrong place

[Tobias Getzner]

On Tue, 23 Sep 2014 10:22:45 +0200, Tobias Getzner wrote:

> This was quite painful to isolate, but I’ve now identified a minimal
> configuration which should trigger this bug.
> 
> ──
> ;; BEGIN minimal.el
> (add-to-list 'load-path (expand-file-name "~/.emacs.d/elpa/org-20140922"))
> 
> ;; Example needs sh; might also trigger with other langs.
> (org-babel-do-load-languages
>   'org-babel-load-languages
>   '((sh .t)))
> 
> (fset 'yes-or-no-p 'y-or-n-p)
> 
> (defun my-org-mode-hook ()
>(follow-mode))
> (add-hook 'org-mode-hook 'my-org-mode-hook)
> ;; END minimal.el
> ──
> 
> This seems rather bizarre. Both follow-mode and the y-or-n-p alias work
> in isolation, but when both are used at the same time, I observe the
> bug initially described.

I’ve found this bug might be related to [1], where org-mode seems to trip
when both follow-mode and TeX-source-correlate-mode are active. [1] does
not seem to interact with aliasing yes-or-no-p, though.

[1] http://article.gmane.org/gmane.emacs.orgmode/91009

Re: [O] org-element-at-point fails in programming-modes

[Thorsten Jolitz]

Nicolas Goaziou  writes:

> Hello,
>
> Thorsten Jolitz  writes:
>
>> Ok, thanks, that sounds promising. OTOH, is the use of "\\S-" really
>> mandatory,
>
> No, it isn't.
>
>> couldn't a more robust construct be used, either something
>> like this (untested) regexp:
>>
>> ,
>> | "[^[:space:]\\n]+"
>> `
>
> AFAIK, [:space:] is not compatible with XEmacs. It could be "[^
> \r\t\n]+", but even this could be too broad (e.g., "#+BEGIN_..."). We
> could also limit block names to alphanumeric characters and a bunch of
> symbols.

I noticed this issue again when calling `org-element-at-point` with
point before the stars in 

,
| ** [#A] whatsup :mytag:it:
| hello world
`

in an emacs-lisp-mode buffer - it results in:

,
| (paragraph (:begin 193 :end 246 :contents-begin 206 :contents-end 245
| :post-blank 1 :post-affiliated 206 ...))
`

so it kind-of works outside org major-mode, but not correctly due to
character-class problem in the regexp(s).

PS

My org-mode is up to date

#+BEGIN_SRC emacs-lisp
 (call-interactively 'org-version)
#+END_SRC

#+results:
: Org-mode version 8.3beta (release_8.3beta-277-g698705 @
/usr/share/emacs/24.3/lisp/org/lisp/)

-- 
cheers,
Thorsten

[O] [BUG] void-variable `org-planning-line-re'

[Thorsten Jolitz]

Hi List, 

seems it was renamed to

,[ C-h v org-planning-or-clock-line-re RET ]
| org-planning-or-clock-line-re is a variable defined in `org.el'.
| Its value is [...]
| Documentation:
| Matches a line with planning info.
| Matched keyword is in group 1.
`

Calling 'org-element-at-point on 

#+BEGIN_ORG
 #+NAME: foo
#+END_ORG

=> 

,
| Debugger entered--Lisp error: (void-variable org-planning-line-re)
|   org-element--current-element(163 element planning nil)
|   [...]
|   org-element--parse-to(16)
|   org-element-at-point()
|   eval((org-element-at-point) nil)
|   eval-expression((org-element-at-point) nil)
|   call-interactively(eval-expression nil nil)
`

PS

#+BEGIN_SRC emacs-lisp
 (call-interactively 'org-version)
#+END_SRC

#+results:
: Org-mode version 8.3beta (release_8.3beta-277-g698705 @
/usr/share/emacs/24.3/lisp/org/lisp/)


-- 
cheers,
Thorsten

Re: [O] [BUG] void-variable `org-planning-line-re'

[Thorsten Jolitz]

Thorsten Jolitz  writes:

sorry for the noise, and Emacs restart fixed the issue.

> Hi List, 
>
> seems it was renamed to
>
> ,[ C-h v org-planning-or-clock-line-re RET ]
> | org-planning-or-clock-line-re is a variable defined in `org.el'.
> | Its value is [...]
> | Documentation:
> | Matches a line with planning info.
> | Matched keyword is in group 1.
> `
>
> Calling 'org-element-at-point on 
>
> #+BEGIN_ORG
>  #+NAME: foo
> #+END_ORG
>
> => 
>
> ,
> | Debugger entered--Lisp error: (void-variable org-planning-line-re)
> |   org-element--current-element(163 element planning nil)
> |   [...]
> |   org-element--parse-to(16)
> |   org-element-at-point()
> |   eval((org-element-at-point) nil)
> |   eval-expression((org-element-at-point) nil)
> |   call-interactively(eval-expression nil nil)
> `
>
> PS
>
> #+BEGIN_SRC emacs-lisp
>  (call-interactively 'org-version)
> #+END_SRC
>
> #+results:
> : Org-mode version 8.3beta (release_8.3beta-277-g698705 @
> /usr/share/emacs/24.3/lisp/org/lisp/)

-- 
cheers,
Thorsten

[O] [BUG] Mark-up handling chokes on unicode whitespace

[Tobias Getzner]

When mark-up such as =monospace=, /italic/, etc. is preceded by a 
non-8bit whitespace, e. g., «narrow no-break space» (U+202F) or «no-break 
space» (U+00A0), org-mode will not recognize the mark-up content 
correctly; i. e., this content will fail to be syntax-highlighted, and 
the mark-up syntax will be exported in verbatim by the exporter.

Best regards,
Tobias

[O] [patchattached] Store link to url of eww

[marcowahlsoft]

Hello all,

since eww comes bundled with Emacs nowadays it feels natural to be able
store a link to the current url of an eww buffer.  This functionality
has already been in place for w3m for a while.

Find a respective patch attached.  I hope the fact that the patch is
attached is acceptable as well as the patch itself.


Best wishes,  Marco
-- 
http://www.wahlzone.de
PGP: 0x0A3AE6F2
>From a4ead864a14931ef2a8dd43719fb6ee90861d346 Mon Sep 17 00:00:00 2001
From: Marco Wahl 
Date: Tue, 23 Sep 2014 09:46:34 +0200
Subject: [PATCH] org-eww: Org-module to store url from eww

* contrib/lisp/org-eww.el: New file

* contrib/lisp/org-eww.el(org-eww-store-link): Hook to store a link.

* contrib/README: Added a line for the org-eww.

* lisp/org.el (org-modules): Add org-eww to the pool of org-modules.

The hook gets hooked in the module.

The file is more or less a fraction of the org-w3m module with 'w3m'
replaced by 'eww'.

TINYCHANGE
---
 contrib/README  |  1 +
 contrib/lisp/org-eww.el | 54 +
 lisp/org.el |  1 +
 3 files changed, 56 insertions(+)
 create mode 100644 contrib/lisp/org-eww.el

diff --git a/contrib/README b/contrib/README
index e92da14..7bffeee 100644
--- a/contrib/README
+++ b/contrib/README
@@ -29,6 +29,7 @@ org-element.el   --- Parser and applications for Org syntax
 org-elisp-symbol.el  --- Org links to emacs-lisp symbols
 org-eval-light.el--- Evaluate in-buffer code on demand
 org-eval.el  --- The  tag, adapted from Muse
+org-eww.el   --- Store link to url of eww
 org-expiry.el--- Expiry mechanism for Org entries
 org-export-generic.el--- Export framework for configurable backends
 org-git-link.el  --- Provide org links to specific file version
diff --git a/contrib/lisp/org-eww.el b/contrib/lisp/org-eww.el
new file mode 100644
index 000..c25057d
--- /dev/null
+++ b/contrib/lisp/org-eww.el
@@ -0,0 +1,54 @@
+;;; org-eww.el --- Storing link in eww-mode for Org-mode
+
+;; Copyright (C) 2014 Free Software Foundation, Inc.
+
+;; Author: Marco Wahl a
+;; Keywords: link, eww
+;; Homepage: http://orgmode.org
+;;
+;; This file is not part of GNU Emacs.
+;;
+;; This program is free software: you can redistribute it and/or modify
+;; it under the terms of the GNU General Public License as published by
+;; the Free Software Foundation, either version 3 of the License, or
+;; (at your option) any later version.
+
+;; This program is distributed in the hope that it will be useful,
+;; but WITHOUT ANY WARRANTY; without even the implied warranty of
+;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+;; GNU General Public License for more details.
+
+;; You should have received a copy of the GNU General Public License
+;; along with GNU Emacs.  If not, see .
+
+
+;;; Commentary:
+
+;; When this module is active `org-store-link' (often on key C-c l) in
+;; a eww buffer stores a link to the current url of the eww buffer.
+
+;; `org-eww-store-link' below is almost the same as
+;; `org-w3m-store-link' of the org-w3m module.
+
+;; Hint: There are further features in module org-w3m which might be
+;; interesting for org-eww also.
+
+
+;;; Code:
+
+(require 'org)
+
+(add-hook 'org-store-link-functions 'org-eww-store-link)
+(defun org-eww-store-link ()
+  "Store a link to the url of a eww buffer."
+  (when (eq major-mode 'eww-mode)
+(org-store-link-props
+ :type "eww"
+ :link eww-current-url
+ :url (url-view-url t)
+ :description (or eww-current-title eww-current-url
+
+
+(provide 'org-eww)
+
+;;; org-eww.el ends here
diff --git a/lisp/org.el b/lisp/org.el
index b09e72d..0bf91d3 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -640,6 +640,7 @@ For export specific modules, see also `org-export-backends'."
 	(const :tag "C  eshell Support for links to working directories in eshell" org-eshell)
 	(const :tag "C  eval-light:Evaluate inbuffer-code on demand" org-eval-light)
 	(const :tag "C  eval:  Include command output as text" org-eval)
+	(const :tag "C  eww:   Store link to url of eww" org-eww)
 	(const :tag "C  expiry:Expiry mechanism for Org-mode entries" org-expiry)
 	(const :tag "C  favtable:  Lookup table of favorite references and links" org-favtable)
 	(const :tag "C  git-link:  Provide org links to specific file version" org-git-link)
-- 
2.1.0

Re: [O] Managing articles in orgmode and collaboration

[Christoph Groth]

Jorge A. Alfaro-Murillo wrote:

Perhaps I am biased because I learned LaTeX and BibTeX before 
Org, but I think that for references BibTeX (plus a little bit 
of emacs configuration) has everything I could need. I guess if 
you are more used to Org, it might be worth to invest time and 
come up with a org-based solution. Please keep us posted, I find 
this a very interesting thread.


This is an update about my experiments so far.  Please comment! 
This is my current setup:


All the articles (mostly PDF files) are kept in one directory. 
There’s also an index.org file in there with headlines like this


--8<---cut here---start->8---
** 
  [[file:vazifeh13-electromagnetic_response_weyl.pdf][Electromagnetic 
  Response of Weyl Semimetals]]

:PROPERTIES:
:TITLE:Electromagnetic Response of Weyl Semimetals
:BTYPE:article
:ID:   vazifeh13-electromagnetic_response_weyl
:AUTHOR:   Vazifeh, M. M. and Franz, M.
:JOURNAL:  Phys. Rev. Lett.
(…)
:END:
Some comments/notes with links and in-line formulas.
--8<---cut here---end--->8---

These entries are created by org-bibtex-yank, Emacs’ bibtex is 
configured to generate the unique IDs (authorYY-three_first_words 
should be sufficiently unique in practice).


This setup works pretty well:

- Adding new articles is easy (there's still ample room for 
 improvement).
- Opening associated the associated article files and other links 
 works well.
- It’s easy to add notes (with in-line maths!) and do simple 
 searches.
- Linking from and to other org files (agenda, project-specific 
 notes) is possible.
- Additional attachment files (e.g. whiteboard photos from a 
 discussion) can added with org-attach.
- org-bibtex provides support to put entries into project-specific 
 bibtex files (org-bibtex-export-to-kill-ring).
- Thanks to the non-random unique IDs, it’s possible to jump to 
 articles in the library from references in latex files, even if 
 the key scheme in the latex file differs from the one used in 
 index.org.


But not all is good:

- Scaling: Some simple tests seem to indicate that org mode 
 becomes too sluggish with files of about 50k lines.  This is a 
 dimension that could be easily reached over 10 years if the file 
 grows by 20 lines per day on average.  This is not a problem in 
 the beginning, but if the scheme does not scale to a few 
 thousand entries, this renders the whole idea way less 
 interesting.


- More advanced searching is lacking: AFAIK org mode currently 
 does not support searching for articles of a given author that 
 also contain a given keyword in the notes.


Any insights about these two problems?  Perhaps the scaling could 
be managed by splitting index.org into several files (by year for 
example).  But how to search then?  It's probably not a good idea 
to add all the bibliography org-files into the agenda.  (Is there 
a way to have a secondary list of agenda files?)  Perhaps the 
solution for both problems would be to write a fast commandline 
query tool for such org-databases?  The tool could even use a fast 
cache if necessary.

Re: [O] TODO items in lists (not headings)

[Gary Oberbrunner]

On Thu, Sep 18, 2014 at 2:49 PM, Gary Oberbrunner 
wrote:

>
>
> On Thu, Sep 18, 2014 at 12:23 PM, Subhan Michael Tindall <
> subh...@familycareinc.org> wrote:
>
>>  Lists are very explicitly not intended to contain TODO items.
>>
>> Checkboxes provide a bit of this functionality, sort of a ‘TODO lite’
>>
>> ...
>>
>> The problem is that list items/checkbox items are NOT headlines, and all
>> the TODO code etc. is tied to headlines.
>>
>>
>>
>> I haven’t looked at the code but I suspect an extensive rewrite to
>> integrate it with the rest of the headline code.  Not as much if it’s kept
>> as an isolated extension.
>>
>>
>>
>
> I suspected as much.  Although having TODOs in lists would be awesome,
> checkboxes will do for me now.
>

One more followup on this: it turns out I don't need to use plain lists
nearly as often as I had thought!  I didn't understand that org-mode export
automatically makes headers greater than N into lists (at least with the
H:N option).   So in many cases I can actually use headers (including
TODOs) and get all the benefits there (including not just TODOs but
attributes and so on) while still having my exported document look like
bulleted lists.  Org-mode ftw!

-- 
Gary

[O] Keeping metadata/notes about files and directories

[Christoph Groth]

Dear all,

I just wrote under the subject “Re: Managing articles in org mode 
and collaboration”.  This posting puts the other one in a broader 
context.


While thinking about organizing articles, I asked myself: Wouldn’t 
it be useful to keep metadata/notes about *various* kinds of 
files/sub-directories/projects inside org-mode (or something 
similar)?


One example is a collection of programming projects.  Just like 
for articles, it would be useful to add notes and metadata to each 
project.  The same is true for many other archive-like collections 
of things that grow over time.  The same problems appear as 
described in the other posting (namely scaling and searching).


I know that there have been discussions about this in the past, 
and I know that there’s org-annotate-file.  Is there anyone who 
uses a scheme like this (for >1000 items, say) in practice?


Christoph

Re: [O] Managing articles in orgmode and collaboration

[Jorge A. Alfaro-Murillo]

Christoph Groth writes: 

But not all is good: 

- Scaling: Some simple tests seem to indicate that org mode  
  becomes too sluggish with files of about 50k lines.  This is a 
  dimension that could be easily reached over 10 years if the 
  file  grows by 20 lines per day on average.  This is not a 
  problem in  the beginning, but if the scheme does not scale to 
  a few  thousand entries, this renders the whole idea way less 
  interesting.
- More advanced searching is lacking: AFAIK org mode currently  
  does not support searching for articles of a given author that 
  also contain a given keyword in the notes. 
Any insights about these two problems? Perhaps the scaling could 
be managed by splitting index.org into several files (by year 
for example). But how to search then? It's probably not a good 
idea to add all the bibliography org-files into the agenda. (Is 
there a way to have a secondary list of agenda files?) Perhaps 
the solution for both problems would be to write a fast 
commandline query tool for such org-databases? The tool could 
even use a fast cache if necessary. 


BibTeX provides bibtex-search-entries (in a bib file it is bound 
to C-c C-a), which searches for entries with a certain field 
matching a regexp.  Perhaps you want to take advantage of that 
function to direct your org searches to bib files and back. Check 
also bibtex-files and bibtex-search-entry-globally, since you 
would then be able to split the org files and export into several 
bib files if a single bib file proves too much. My current 
articles.bib is about 14k lines, and it is not sluggish at all, 
but I will have to wait a couple of years until I tell you if a 
50k one would be.


Best,

--
Jorge.

Re: [O] [ Bug] tsia-{up, down} sorting strategy not working for tags search agendas

[Subhan Michael Tindall]

> -Original Message-
> From: emacs-orgmode-bounces+subhant=familycareinc@gnu.org
> [mailto:emacs-orgmode-bounces+subhant=familycareinc@gnu.org] On
> Behalf Of Sebastien Vauban
> Sent: Tuesday, September 23, 2014 12:57 AM
> To: emacs-orgmode@gnu.org
> Subject: Re: [O] [ Bug] tsia-{up, down} sorting strategy not working for tags
> search agendas
> 
> Subhan Michael Tindall wrote:
> > I have the following agendas (among others) defined:
> > ("x" "Last worked" ((alltodo "" ( (org-agenda-sticky nil)
> > (org-agenda-sorting-strategy (quote (tsia-up
> > todo-state-down))) ("y" "Last worked2" ((tags "LastWorked={.+}" (
> > (org-agenda-sticky nil)
> > (org-agenda-sorting-strategy (quote (tsia-up
> > todo-state-down)))
> >
> > I have a property defined in headlines that have been worked on:
> > :PROPERTIES:
> > :LastWorked: [2014-09-02 Tue 16:02]
> > :END:
> >
> > TODOs etc that have not been worked yet don't have this property.
> >
> > The top search ("x") creates an agenda with items with a LastWorked
> > property sorted with the least recent first, down to most recent,
> > followed by any items with the LastWorked property unset sorted by todo-
> state.
> >
> > The bottom search ("y") creates an agenda with only items with
> > LastWorked property set (which I want) but completely ignores the
> > tsia-up sorting strategy and sorts only by todo-state.
> >
> > I have confirmed that org-agenda-sorting-strategy-selected is correct in
> both cases.
> > The only difference is the agenda type (tags vs alltodo)
> >
> > Any ideas where to look for this ?
> 
> I guess it's directly linked to a problem I reported last September. This is
> indeed annoying...
> 
> See issue #29 on http://orgmode.org/worg/org-issues.html (and see the
> pointed thread).
> 
> Best regards,
>   Seb
> 
> --
> Sebastien Vauban
> 
Indeed, it does appear to be the same issue.  I assuming no progress on fixing 
it?
I guess that leaves me with two workarounds (suitable for my purposes anyway):
Use the "alltodo" search type and either
A) write a customized skip function to exclude any entries without a 
'LastWorked' property entry
Or
B) write a customized sort so that empty entries sort to the bottom, not the 
top (possibly in both directions IE
ABCDE for tsia-up, DCBAE for tsia-down
Either of these will get me what I want.  I'm a reasonably competent 
programmer, a minimal elisper, and have almost no familiarity with the org 
code.  Any suggestions on which of these would be easier or more 
straightforward?
I did take a look through the code to see if I could sort this out myself, but 
couldn't really make heads or tails of it.







This message is intended for the sole use of the individual and entity to which 
it is addressed and may contain information that is privileged, confidential 
and exempt from disclosure under applicable law. If you are not the intended 
addressee, nor authorized to receive for the intended addressee, you are hereby 
notified that you may not use, copy, disclose or distribute to anyone the 
message or any information contained in the message. If you have received this 
message in error, please immediately advise the sender by reply email and 
delete the message.  Thank you.

Re: [O] [RFC] [PATCH] Warn about unexpanded macros on export

[Grant Rettke]

Aaron may I trouble you to add a flag so that if such errors occur
then the export fails?

>From my perspective, if the document doesn't "compile", then nothing
should succeed.

Compile includes export from my perspective.

On Mon, Sep 22, 2014 at 10:25 PM, Aaron Ecay  wrote:
> Hi Nicolas,
>
> 2014ko irailak 19an, Nicolas Goaziou-ek idatzi zuen:
>>
>> Certainly not a message, due to asynchronous export.
>
> Very good point.
>
>>
>>> 2. Since this is a feature that many backends will want to use, should
>>> we introduce a new “abstract” backend from which other backends can
>>> inherit, which incorporates this feature, and others like it in the
>>> future?  The idea would be similar to prog-mode in emacs, the major
>>> mode from which programming-language modes can derive.  The
>>> alternative is adding the (macro . org-export-macro-warn) entry
>>> manually to all the relevant backends, and relying on future backend
>>> authors to do the same.
>>>
>>> 3. Should this even be implemented as part of the backend’s
>>> translate-alist, or at a lower level?
>>
>> Don't bother with export back-ends, they never get to see macros, which
>> are expanded very early in the export process. This explains, for
>> example, why there is no `macro' translator.
>
> Um...but the patch I sent works precisely by defining a macro translator,
> which does get called for any unexpanded (because undefined) macros.  I
> guess you’re saying the code ought to block this at a lower/earlier level.
>
>>
>> You have two options. Either report an error, as you suggested, or
>> insert an obnoxious message in the output, e.g., "UNKNOWN MACRO", à la
>> "DEFINITION NOT FOUND." for footnote definitions. In any case, this
>> should happen in "org-macro.el", not in the export framework.
>
> I think error is better than obnoxious message, because it’s possible
> for the latter to slip through into a “production” document.  (We ought
> to proofread our documents carefully, of course...but no one’s perfect).
>
> One issue is that the exporter does two macro expansion passes – one
> for garden-variety macros, and the second for author, date, email, and
> title.  So, we can’t make the macro expansion unconditionally barf on
> undefined macros (since for the first pass e.g. author is undefined).
> I see three options:
> 1. explicitly whitelist the few “blessed” macros like author, and error
>on any other undefined macro
> 2. add an optional “final” arg to org-macro-replace-all, which will
>activate the undefined checking only if non-nil, and pass this flag
>in the exporter’s second (and last) call to org-macro-replace-all
> 3. in ‘org-export-as’, manually walk the parse tree after expanding
>macros, and make sure no 'macro type objects are left
>
> WDYT?
>
> --
> Aaron Ecay
>



-- 
Grant Rettke
g...@wisdomandwonder.com | http://www.wisdomandwonder.com/
“Wisdom begins in wonder.” --Socrates
((λ (x) (x x)) (λ (x) (x x)))
“Life has become immeasurably better since I have been forced to stop
taking it seriously.” --Thompson

Re: [O] [BUG] Mark-up handling chokes on unicode whitespace

[Aaron Ecay]

Hi Tobias,

2014ko irailak 23an, Tobias Getzner-ek idatzi zuen:
> 
> When mark-up such as =monospace=, /italic/, etc. is preceded by a 
> non-8bit whitespace, e. g., «narrow no-break space» (U+202F) or «no-break 
> space» (U+00A0), org-mode will not recognize the mark-up content 
> correctly; i. e., this content will fail to be syntax-highlighted, and 
> the mark-up syntax will be exported in verbatim by the exporter.

You will need to change the variable org-emphasis-regexp-components; see
the documentation thereof.

-- 
Aaron Ecay

Re: [O] [patchattached] Store link to url of eww

[Aaron Ecay]

Hi Marco,

Thanks for your patch.  TINYCHANGES can only be smaller than 15 lines,
though, and your patch has more than that (even if we discount
boilerplate like the license notice).  So you should probably do the
copyright assignment which is described at
.

-- 
Aaron Ecay

[O] How to utilize the vc package inside of the edit source block buffer?

[Grant Rettke]

Good afternoon,

The ability to org-edit-special inside of source block is truly priceless.

There is a delightful workflow to be found with approach.

It has got me spending more and more time in the edit buffer though,
wanting to utilize
vc-next-action to initiate a commit. This is not possible because the
buffer is not associated
with a file.

Is there some way to get tell Emacs to execute the action on the
source buffer from which the
source edit block buffer originated?

My apologies as I have not been able to locate the post where this
topic was originally discussed.

Kind regards,

-- 
Grant Rettke
g...@wisdomandwonder.com | http://www.wisdomandwonder.com/
“Wisdom begins in wonder.” --Socrates
((λ (x) (x x)) (λ (x) (x x)))
“Life has become immeasurably better since I have been forced to stop
taking it seriously.” --Thompson

Re: [O] [patchattached] Store link to url of eww

[Aaron Ecay]

Hi again,

2014ko irailak 23an, Aaron Ecay-ek idatzi zuen:
> 
> Hi Marco,
> 
> Thanks for your patch.  TINYCHANGES can only be smaller than 15 lines,
> though, and your patch has more than that (even if we discount
> boilerplate like the license notice).  So you should probably do the
> copyright assignment which is described at
> .

I should have said: the copyright assignment isn’t strictly needed for
code in contrib.  But since this module is an interface between two emacs
built-in modules, it is a good candidate for moving to core eventually,
where the copyright assignment would be needed.

So, I didn’t mean to imply that the copyright assignment would be a hard
condition on merging your patch, but IMO it would be helpful.

-- 
Aaron Ecay

Re: [O] [RFC] [PATCH] Warn about unexpanded macros on export

[Aaron Ecay]

Hi Grant,

2014ko irailak 23an, Grant Rettke-ek idatzi zuen:
> 
> Aaron may I trouble you to add a flag so that if such errors occur
> then the export fails?
> 
> From my perspective, if the document doesn't "compile", then nothing
> should succeed.
> 
> Compile includes export from my perspective.

Indeed, that’s the direction that the next iteration of this patch will
move, motivated by your and Nicolas’s comments.

Thanks,

-- 
Aaron Ecay

Re: [O] [bug?] org-copy-face doesn’t add faces to org-faces customize group

[Aaron Ecay]

Hi Seb,

2014ko irailak 23an, Sebastien Vauban-ek idatzi zuen:
> 
> Hi Aaron,
> 
> Aaron Ecay wrote:
>> 2014ko abuztuak 29an, Sebastien Vauban-ek idatzi zuen:
>>> I think it's related to an Emacs bug (#16440) which I reported on the
>>> Org mailing list in February.
>> 
>> I don’t completely understand what is going on in that bug report.  My
>> proposal is to convert org-copy-face to defface.
> 
> I think this is "the right thing" (TM).
> 
>> I can’t tell if this would fix your problem or not, but if it’s
>> exclusive to the faces I listed in my previous email the answer is
>> probably “yes.”
> 
> From what I can see, yes, the faces which are wrongly displayed (before
> re-applying the theme) match the ones defined by `org-copy-face'.  So,
> this seems the right way to go.

OK, thanks for the followup.  I’m attaching the patch to this email.  If
I don’t hear any further feedback, I’ll commit it to master in a few
days.
>From 128726a88ca2ec2232071cd9a6d7869df01fd953 Mon Sep 17 00:00:00 2001
From: Aaron Ecay 
Date: Tue, 23 Sep 2014 13:21:22 -0400
Subject: [PATCH] org-faces: remove org-copy-face
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

* lisp/org-faces.el (org-copy-face): Remove function.
(org-checkbox-statistics-todo, org-checkbox-statistics-done)
(org-block-begin-line, org-block-end-line, org-quote)
(org-verse, org-agenda-date, org-agenda-date-today)
(org-agenda-clocking, org-agenda-date-weekend)
(org-agenda-current-time, org-mode-line-clock)
(org-mode-line-clock-overrun): Convert to `defface' from
`org-copy-face'.

The ‘org-copy-face’ function didn’t properly deal with face
customizations and color themes.
---
 lisp/org-faces.el | 96 +++
 1 file changed, 54 insertions(+), 42 deletions(-)

diff --git a/lisp/org-faces.el b/lisp/org-faces.el
index 6e62ad0..36f810e 100644
--- a/lisp/org-faces.el
+++ b/lisp/org-faces.el
@@ -31,19 +31,6 @@
 (require 'org-macs)
 (require 'org-compat)
 
-(defun org-copy-face (old-face new-face docstring &rest attributes)
-  (unless (facep new-face)
-(if (fboundp 'set-face-attribute)
-	(progn
-	  (make-face new-face)
-	  (set-face-attribute new-face nil :inherit old-face)
-	  (apply 'set-face-attribute new-face nil attributes)
-	  (set-face-doc-string new-face docstring))
-  (copy-face old-face new-face)
-  (if (fboundp 'set-face-doc-string)
-	  (set-face-doc-string new-face docstring)
-(put 'org-copy-face 'lisp-indent-function 2)
-
 (when (featurep 'xemacs)
   (put 'mode-line 'face-alias 'modeline))
 
@@ -427,12 +414,15 @@ determines if it is a foreground or a background color."
   "Face for checkboxes."
   :group 'org-faces)
 
+(defface org-checkbox-statistics-todo
+  '((t (:inherit org-todo)))
+  "Face used for unfinished checkbox statistics."
+  :group 'org-faces)
 
-(org-copy-face 'org-todo 'org-checkbox-statistics-todo
-  "Face used for unfinished checkbox statistics.")
-
-(org-copy-face 'org-done 'org-checkbox-statistics-done
-  "Face used for finished checkbox statistics.")
+(defface org-checkbox-statistics-done
+  '((t (:inherit org-done)))
+  "Face used for finished checkbox statistics."
+  :group 'org-faces)
 
 (defcustom org-tag-faces nil
   "Faces for specific tags.
@@ -537,11 +527,15 @@ follows a #+DATE:, #+AUTHOR: or #+EMAIL: keyword."
   :group 'org-faces
   :version "22.1")
 
-(org-copy-face 'org-meta-line 'org-block-begin-line
-  "Face used for the line delimiting the begin of source blocks.")
+(defface org-block-begin-line
+  '((t (:inherit org-meta-line)))
+  "Face used for the line delimiting the begin of source blocks."
+  :group 'org-faces)
 
-(org-copy-face 'org-meta-line 'org-block-end-line
-  "Face used for the line delimiting the end of source blocks.")
+(defface org-block-end-line
+  '((t (:inherit org-block-begin-line)))
+  "Face used for the line delimiting the end of source blocks."
+  :group 'org-faces)
 
 (defface org-verbatim
   (org-compatible-face 'shadow
@@ -557,10 +551,15 @@ follows a #+DATE:, #+AUTHOR: or #+EMAIL: keyword."
   :group 'org-faces
   :version "22.1")
 
-(org-copy-face 'org-block 'org-quote
-  "Face for #+BEGIN_QUOTE ... #+END_QUOTE blocks.")
-(org-copy-face 'org-block 'org-verse
-  "Face for #+BEGIN_VERSE ... #+END_VERSE blocks.")
+(defface org-quote
+  '((t (:inherit org-block)))
+  "Face for #+BEGIN_QUOTE ... #+END_QUOTE blocks."
+  :group 'org-faces)
+
+(defface org-verse
+  '((t (:inherit org-block)))
+  "Face for #+BEGIN_VERSE ... #+END_VERSE blocks."
+  :group 'org-faces)
 
 (defcustom org-fontify-quote-and-verse-blocks nil
   "Non-nil means, add a special face to #+begin_quote and #+begin_verse block.
@@ -597,21 +596,28 @@ content of these blocks will still be treated as Org syntax."
   "Face used in agenda for captions and dates."
   :group 'org-faces)
 
-(org-copy-face 'org-agenda-structure 'org-agenda-date
-  "Face used in agenda for normal days.")
+(defface org-agenda-date
+  '((t (:inherit org-agenda-

Re: [O] [RFC] [PATCH] Warn about unexpanded macros on export

[Jacob Gerlach]

While I expect that there's no code overlap with macro expansion, I asked
about similar "stop on unresolved content" behavior with respect to links
here: http://article.gmane.org/gmane.emacs.orgmode/90010/

That discussion died off so I thought I'd bring up the topic again here.

Would it be possible to cause export to stop (configurably, as discussed)
when a link can't be resolved instead of just applying a special format
(i.e. org-latex-link-with-unknown-path-format)

On Tue, Sep 23, 2014 at 1:18 PM, Aaron Ecay  wrote:

> Hi Grant,
>
> 2014ko irailak 23an, Grant Rettke-ek idatzi zuen:
> >
> > Aaron may I trouble you to add a flag so that if such errors occur
> > then the export fails?
> >
> > From my perspective, if the document doesn't "compile", then nothing
> > should succeed.
> >
> > Compile includes export from my perspective.
>
> Indeed, that’s the direction that the next iteration of this patch will
> move, motivated by your and Nicolas’s comments.
>
> Thanks,
>
> --
> Aaron Ecay
>
>

Re: [O] resizing windows from an org buffer, reqest for org-shiftcontrol-final-hook

[Aaron Ecay]

Hi Bradley,

2014ko irailak 16an, Brady Trainor-ek idatzi zuen:
> 
> I have
> 
> (global-set-key (kbd "S-C-") 'shrink-window-horizontally)
> (global-set-key (kbd "S-C-") 'enlarge-window-horizontally)
> (global-set-key (kbd "S-C-") 'shrink-window)
> (global-set-key (kbd "S-C-") 'enlarge-window)
> 
> in my init file, as suggested at 
> http://www.emacswiki.org/emacs-en/WindowResize. However, when I am in an 
> org file, the binding fails.
> 
> I had hoped that (setq org-support-shift-select t) would fix this, but 
> it only seems to want to allow selection.
> 
> A solution might be similar to the one
> 
> ;; quick keys for switching windows
> (windmove-default-keybindings)
> ;; fix windmove in org-mode
> (add-hook 'org-shiftup-final-hook 'windmove-up)
> (add-hook 'org-shiftleft-final-hook 'windmove-left)
> (add-hook 'org-shiftdown-final-hook 'windmove-down)
> (add-hook 'org-shiftright-final-hook 'windmove-right)
> 
> as suggested at http://orgmode.org/manual/Conflicts.html.
> 
> Looking at the code in org.el, it seems org-shiftcontrolup and the like 
> were not so lucky to get such a final-hook. Can this be added? I am 
> currently using package.el org-mode, so I may not immediately get to try 
> it out, but would look forward to adding it to my workflow soon.

Rather than adding a hook to these functions, perhaps we should add
another branch to their conditionals which tries (lookup-key global-map
(this-command-keys)), and calls that function if it exists.  The error
would be raised as before if there is no binding for the key in
global-map.

How’s your elisp?  Would you feel up to trying to create such a patch?

-- 
Aaron Ecay

Re: [O] [BUG] Mark-up handling chokes on unicode whitespace

[Tobias Getzner]

Hello Aaron!

On Tue, 23 Sep 2014 13:03:06 -0400, Aaron Ecay wrote:

> 2014ko irailak 23an, Tobias Getzner-ek idatzi zuen:
>> 
>> When mark-up such as =monospace=, /italic/, etc. is preceded by a
>> non-8bit whitespace, e. g., «narrow no-break space» (U+202F) or
>> «no-break space» (U+00A0), org-mode will not recognize the mark-up
>> content correctly
> 
> You will need to change the variable org-emphasis-regexp-components; see
> the documentation thereof.

Thank you very much! This seems to do it.

Might I suggest amending unicode whitespace to the default? That variable 
seems a bit opaque and I might probably never have discovered it on my 
own; it also appears as if one has to ensure that this is set before org-
mode is «required», and one cannot easily just extend the default without 
also setting the rest. For type-setting purposes, at least the class of 
non-breaking whitespace is very useful.

At first I thought it might be easy to cleanly solve such problems by 
using the whitespace character class throughout, but to my chagrin it 
seems that at least «search-forward-regexp» will only match 8-bit 
whitespace this way, so I suppose Emacs regex isn’t aware of non-ASCII 
whitespace? :'| 

Best,
Tobias

Re: [O] Call speed-commands with prefix-arg?

[Aaron Ecay]

Hi Thorsten,

2014ko irailak 18an, Thorsten Jolitz-ek idatzi zuen:
> 
> Hi List, 
> 
> is there a way to call Org speed-commands [fn:1] with a prefix-arg?
> Does not work for me ...

The attached patch should allow this.  You can use C-u N X or C-N X (where
N is some digits and X a speed command key).  I’ll commit it to master in a
few days (along with an entry in ORG-NEWS), unless there is any
feedback.

It might be cool to also allow digits 0-9 and hyphen (for minus) to work
as prefix args when in speed command position.  But that’s more
complicated.
>From f4abc5c57764fc36d7405be6b6c2f5cd63396d8d Mon Sep 17 00:00:00 2001
From: Aaron Ecay 
Date: Tue, 23 Sep 2014 13:54:47 -0400
Subject: [PATCH] allow speed commands to have prefix args

* lisp/org.el (org-self-insert-command): Allow speed commands to be
invoked with prefix args.
---
 lisp/org.el | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/lisp/org.el b/lisp/org.el
index b09e72d..9815eb4 100755
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -19693,9 +19693,11 @@ overwritten, and the table is not marked as requiring realignment."
   (org-check-before-invisible-edit 'insert)
   (cond
((and org-use-speed-commands
-	 (setq org-speed-command
-	   (run-hook-with-args-until-success
-		'org-speed-command-hook (this-command-keys
+	 (let ((kv (this-command-keys-vector)))
+	   (setq org-speed-command
+		 (run-hook-with-args-until-success
+		  'org-speed-command-hook
+		  (make-string 1 (aref kv (1- (length kv
 (cond
  ((commandp org-speed-command)
   (setq this-command org-speed-command)
-- 
2.1.0

-- 
Aaron Ecay

Re: [O] [bug?] org-copy-face doesn’t add faces to org-faces customize group

[Sebastien Vauban]

Hi Aaron,

Aaron Ecay wrote:
> 2014ko irailak 23an, Sebastien Vauban-ek idatzi zuen:
>> Aaron Ecay wrote:
>>> 2014ko abuztuak 29an, Sebastien Vauban-ek idatzi zuen:
 I think it's related to an Emacs bug (#16440) which I reported on the
 Org mailing list in February.
>>> 
>>> I don’t completely understand what is going on in that bug report.  My
>>> proposal is to convert org-copy-face to defface.
>> 
>> I think this is "the right thing" (TM).
>> 
>>> I can’t tell if this would fix your problem or not, but if it’s
>>> exclusive to the faces I listed in my previous email the answer is
>>> probably “yes.”
>> 
>> From what I can see, yes, the faces which are wrongly displayed (before
>> re-applying the theme) match the ones defined by `org-copy-face'.  So,
>> this seems the right way to go.
>
> OK, thanks for the followup.  I’m attaching the patch to this email.  If
> I don’t hear any further feedback, I’ll commit it to master in a few
> days.

I'd say: commit it now, so that it really gets to a broad audience.

Anyway, would there be problems, they would be very, very limited: face
problems, that's all!

Best regards,
  Seb

-- 
Sebastien Vauban

Re: [O] [BUG] Mark-up handling chokes on unicode whitespace

[Aaron Ecay]

Hi Tobias,

2014ko irailak 23an, Tobias Getzner-ek idatzi zuen:
> 
> Hello Aaron!
> 
> On Tue, 23 Sep 2014 13:03:06 -0400, Aaron Ecay wrote:
> 
>> You will need to change the variable org-emphasis-regexp-components; see
>> the documentation thereof.
> 
> Thank you very much! This seems to do it.
> 
> Might I suggest amending unicode whitespace to the default? That variable 
> seems a bit opaque and I might probably never have discovered it on my 
> own; it also appears as if one has to ensure that this is set before org-
> mode is «required», and one cannot easily just extend the default without 
> also setting the rest. For type-setting purposes, at least the class of 
> non-breaking whitespace is very useful.

org-emphasis-regexp-components is known to be a wart.  You can search
for posts on the mailing list.  Some people are trying to figure out how
to get rid of it.  (You can search in particular for Nicolas Goaziou’s
posts...)  Here’s one thread where you can see the lay of the land:
.

All that to say, the longer-term solution is to figure out some radically
different approach.  In the meantime though, if you can provide a list of
characters (by unicode name and/or code point) that you think should be
added to that variable, someone might be able to add them.  (I probably
would not make such a change on my own, but would wait for feedback from
Nicolas, Bastien, or one of the other maintainer-esque figures on the
list).  On the other hand, they might say “making such a change in org’s
core is just restacking the deck chairs on the Titanic,” which would
also be a reasonable position for them to take IMO.

> 
> At first I thought it might be easy to cleanly solve such problems by 
> using the whitespace character class throughout, but to my chagrin it 
> seems that at least «search-forward-regexp» will only match 8-bit 
> whitespace this way, so I suppose Emacs regex isn’t aware of non-ASCII 
> whitespace? :'|

I don’t really know anything about this...it’s unfortunate if true
though.

-- 
Aaron Ecay

[O] Download of constants.el not working

[H. Dieter Wilhelm]

Hello (),

I can't download constants.el from

https://staff.fnwi.uva.nl/c.dominik/Tools/constants/index.html

would you mind to post a copy or another link?

Thanks
Dieter
-- 
Best wishes
H. Dieter Wilhelm
Darmstadt, Germany

Re: [O] How to utilize the vc package inside of the edit source block buffer?

[Aaron Ecay]

Hi Grant,

2014ko irailak 23an, Grant Rettke-ek idatzi zuen:
> 
> Good afternoon,
> 
> The ability to org-edit-special inside of source block is truly priceless.
> 
> There is a delightful workflow to be found with approach.
> 
> It has got me spending more and more time in the edit buffer though,
> wanting to utilize
> vc-next-action to initiate a commit. This is not possible because the
> buffer is not associated
> with a file.
> 
> Is there some way to get tell Emacs to execute the action on the
> source buffer from which the
> source edit block buffer originated?

One approach might be to advise the vc commands like (pseudocode):

(defadvice vc-foo (around org-src activate)
  (when (in-src-edit-p)
(org-edit-src-exit))
  ad-do-it)

-- 
Aaron Ecay

Re: [O] [Bug?] Results of code block printed in wrong place

[Aaron Ecay]

Hi Tobias,

I can reproduce this.

2014ko irailak 23an, Tobias Getzner-ek idatzi zuen:
> 
> Hello Nicolas,
> 
> On Mo, 2014-09-22 at 17:29 +0200, Nicolas Goaziou wrote:
>> FWIW, I cannot reproduce it.
> 
> This was quite painful to isolate, but I’ve now identified a minimal
> configuration which should trigger this bug.
> 
> ──
> ;; BEGIN minimal.el
> (add-to-list 'load-path (expand-file-name "~/.emacs.d/elpa/org-20140922"))
> 
> ;; Example needs sh; might also trigger with other langs.
> (org-babel-do-load-languages
>   'org-babel-load-languages
>   '((sh .t)))
> 
> (fset 'yes-or-no-p 'y-or-n-p)
> 
> (defun my-org-mode-hook ()
>(follow-mode))
> (add-hook 'org-mode-hook 'my-org-mode-hook)
> ;; END minimal.el
> ──
>

The file:

=
* heading 1
#+BEGIN_SRC sh :eval never
echo baz
#+END_SRC

* heading 2
#+BEGIN_SRC sh :exports results
echo quux
#+END_SRC
=

I get #+results: quux in the original buffer, not the export buffer (so
that quux is not present in the output of export.)

> This seems rather bizarre. Both follow-mode and the y-or-n-p alias work
> in isolation, but when both are used at the same time, I observe the
> bug initially described. Can you confirm this?

What a fun puzzle!

Babel uses yes-or-no-p to confirm evaluation of the code block on export.
yes-or-no-p is implemented in C whereas y-or-n-p is in elisp, so it must
be the case that the lisp code allows some hook to run, which follow-mode
uses to futz with which buffer/window is current, confusing org-mode.
The C implementation I guess doesn’t run the same hook.

Sounds like the best advice for the moment is “don’t use follow-mode
with org”.  Maybe it’s worth adding to the section on package conflicts
in the manual?

-- 
Aaron Ecay

Re: [O] How to utilize the vc package inside of the edit source block buffer?

[Jonathan Leech-Pepin]

Hello,

On 23 September 2014 14:19, Aaron Ecay  wrote:

> Hi Grant,
>
> 2014ko irailak 23an, Grant Rettke-ek idatzi zuen:
> >
> > Good afternoon,
> >
> > The ability to org-edit-special inside of source block is truly
> priceless.
> >
> > There is a delightful workflow to be found with approach.
> >
> > It has got me spending more and more time in the edit buffer though,
> > wanting to utilize
> > vc-next-action to initiate a commit. This is not possible because the
> > buffer is not associated
> > with a file.
> >
> > Is there some way to get tell Emacs to execute the action on the
> > source buffer from which the
> > source edit block buffer originated?
>
> One approach might be to advise the vc commands like (pseudocode):
>
> (defadvice vc-foo (around org-src activate)
>   (when (in-src-edit-p)
> (org-edit-src-exit))
>   ad-do-it)
>
>
The following would work as a wrapper:

(defun test-buffer ()
  (interactive)
  (when org-edit-src-from-org-mode
(let ((buffer (marker-buffer org-edit-src-beg-marker)))
  (with-current-buffer buffer
(message "%s is current for file: %s"
 (current-buffer)
 (buffer-file-name))

Replace (message ...) with `vc-next-action` or use the above as advice
[adjusting from (when..) to (if..)].

Regards,
Jonathan


> --
> Aaron Ecay
>
>

Re: [O] Call speed-commands with prefix-arg?

[Thorsten Jolitz]

Aaron Ecay  writes:

Hi Aaron,

> 2014ko irailak 18an, Thorsten Jolitz-ek idatzi zuen:
>> 
>> Hi List, 
>> 
>> is there a way to call Org speed-commands [fn:1] with a prefix-arg?
>> Does not work for me ...
>
> The attached patch should allow this.  You can use C-u N X or C-N X (where
> N is some digits and X a speed command key).  I’ll commit it to master in a
> few days (along with an entry in ORG-NEWS), unless there is any
> feedback.

well, here is some positive feedback - thanks for tackling this!
I tried to port this to outshine.el right away, but can't make it to
work. But this might well be due to the fact that I'm on the console, no
X11. 

When I do C-u 4 t (with t for todo in the outshine speed cmds) I simply
get:

,
| ;; ** DONE err
`

Since outshine-self-insert-command is a one-to-one copy of
org-self-insert-command, I guess if the patch works for you, it must be
a console problem that I have. Does your patch work for you on the
console too?

> It might be cool to also allow digits 0-9 and hyphen (for minus) to work
> as prefix args when in speed command position.  But that’s more
> complicated.
>
> From f4abc5c57764fc36d7405be6b6c2f5cd63396d8d Mon Sep 17 00:00:00 2001
> From: Aaron Ecay 
> Date: Tue, 23 Sep 2014 13:54:47 -0400
> Subject: [PATCH] allow speed commands to have prefix args
>
> * lisp/org.el (org-self-insert-command): Allow speed commands to be
> invoked with prefix args.
> ---
>  lisp/org.el | 8 +---
>  1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/lisp/org.el b/lisp/org.el
> index b09e72d..9815eb4 100755
> --- a/lisp/org.el
> +++ b/lisp/org.el
> @@ -19693,9 +19693,11 @@ overwritten, and the table is not marked as 
> requiring realignment."
>(org-check-before-invisible-edit 'insert)
>(cond
> ((and org-use-speed-commands
> -  (setq org-speed-command
> -(run-hook-with-args-until-success
> - 'org-speed-command-hook (this-command-keys
> +  (let ((kv (this-command-keys-vector)))
> +(setq org-speed-command
> +  (run-hook-with-args-until-success
> +   'org-speed-command-hook
> +   (make-string 1 (aref kv (1- (length kv
>  (cond
>   ((commandp org-speed-command)
>(setq this-command org-speed-command)
> -- 
> 2.1.0

-- 
cheers,
Thorsten

Re: [O] [RFC] [PATCH] ox-latex: support :float no with caption for minted listings

[Nicolas Goaziou]

Hello,

Aaron Ecay  writes:

> Thanks for all your feedback.  The patch is now applied on master.

Thank you.

> I’m confused about how ‘org-latex--wrap-label’ works.  It tries to
> put \label commands outside of floats.  That will yield links that
> jump to the preceding section, not the specific point in the document
> where the \label command occurs.  Probably this command should insert
> \phantomsection before the \label, so that resultant links jump to
> the right point.  (I’ll make this change if no one objects.)

I have no objection.

> Merging the functions might only be worth doing if there were any more
> places where \captionof needed to be used.

That's the intent, yes. It would be a waste not to use a package now
residing in the default list. Among the transcoders where
`org-latex--wrap-label' is used, some could probably benefit from
a non-float caption, if requested by the user.


Regards,

-- 
Nicolas Goaziou

Re: [O] [RFC] [PATCH] Warn about unexpanded macros on export

[Nicolas Goaziou]

Hello,

Aaron Ecay  writes:

> Um...but the patch I sent works precisely by defining a macro translator,
> which does get called for any unexpanded (because undefined) macros.

Macros are not expected to be seen by export back-ends. It happens when
a macro is undefined, but this is not a reliable feature.

> I guess you’re saying the code ought to block this at a lower/earlier
> level.

Yes, at "org-macro.el" level.

> I think error is better than obnoxious message, because it’s possible
> for the latter to slip through into a “production” document.  (We ought
> to proofread our documents carefully, of course...but no one’s
> perfect).

Sounds good.

> One issue is that the exporter does two macro expansion passes – one
> for garden-variety macros, and the second for author, date, email, and
> title.  So, we can’t make the macro expansion unconditionally barf on
> undefined macros (since for the first pass e.g. author is undefined).
> I see three options:
> 1. explicitly whitelist the few “blessed” macros like author, and error
>on any other undefined macro
> 2. add an optional “final” arg to org-macro-replace-all, which will
>activate the undefined checking only if non-nil, and pass this flag
>in the exporter’s second (and last) call to org-macro-replace-all
> 3. in ‘org-export-as’, manually walk the parse tree after expanding
>macros, and make sure no 'macro type objects are left
>
> WDYT?

I have no strong opinion here but I lean towards option 2 as the error
stays internal to "org-macro.el" and is only triggered with an optional
argument. It also doesn't require to hardcode special macro names.


Regards,

-- 
Nicolas Goaziou

Re: [O] [RFC] [PATCH] Warn about unexpanded macros on export

[Rasmus]

Hi, 

Aaron Ecay  writes:

>> You have two options. Either report an error, as you suggested, or
>> insert an obnoxious message in the output, e.g., "UNKNOWN MACRO", à la
>> "DEFINITION NOT FOUND." for footnote definitions. In any case, this
>> should happen in "org-macro.el", not in the export framework.

This is pretty annoying for footnotes.

> I think error is better than obnoxious message, because it’s possible
> for the latter to slip through into a “production” document.  (We ought
> to proofread our documents carefully, of course...but no one’s perfect).

I think an error is correct, but the message should be informative,
e.g. "macro MACRO undefined at LINE".

—Rasmus

-- 
Summon the Mothership!

Re: [O] Keeping metadata/notes about files and directories

[Darlan Cavalcante Moreira]

See the custom commands for the agenda in the manual. You can create a
command to do a search in specific files.

The framework would be splitting your big org file into multiple files
and creating a custom search that search only in those particular
files. Of course you would need to change this custom command definition
if you add more files, but with the idea of using one file per year from
the other thread that means updating the custom command only once an
year.

I didn't test this so see how searching in all of these files scale when
compared to searching in one big file, but I imagine it would be faster.

--
Darlan Cavalcante Moreira


Christoph Groth writes:

> Dear all,
>
> I just wrote under the subject “Re: Managing articles in org mode 
> and collaboration”.  This posting puts the other one in a broader 
> context.
>
> While thinking about organizing articles, I asked myself: Wouldn’t 
> it be useful to keep metadata/notes about *various* kinds of 
> files/sub-directories/projects inside org-mode (or something 
> similar)?
>
> One example is a collection of programming projects.  Just like 
> for articles, it would be useful to add notes and metadata to each 
> project.  The same is true for many other archive-like collections 
> of things that grow over time.  The same problems appear as 
> described in the other posting (namely scaling and searching).
>
> I know that there have been discussions about this in the past, 
> and I know that there’s org-annotate-file.  Is there anyone who 
> uses a scheme like this (for >1000 items, say) in practice?
>
> Christoph

Re: [O] Call speed-commands with prefix-arg?

[Aaron Ecay]

Hi Thorsten,

2014ko irailak 23an, Thorsten Jolitz-ek idatzi zuen:
> 
> well, here is some positive feedback - thanks for tackling this!
> I tried to port this to outshine.el right away, but can't make it to
> work. But this might well be due to the fact that I'm on the console, no
> X11. 
> 
> When I do C-u 4 t (with t for todo in the outshine speed cmds) I simply
> get:
> 
> ,
> | ;; ** DONE err
> `
> 
> Since outshine-self-insert-command is a one-to-one copy of
> org-self-insert-command, I guess if the patch works for you, it must be
> a console problem that I have. Does your patch work for you on the
> console too?

It seems to, yes.  Can you test org mode (not outshine) in the console,
and verify that the original patch works for you there?  If it doesn’t,
that needs to be resolved before the patch can be merged.

Thanks,

-- 
Aaron Ecay

Re: [O] Download of constants.el not working

[Aaron Ecay]

Hi Dieter,

The link on the page you linked to is broken, but if you manually change
the URL to the following it works:

https://staff.fnwi.uva.nl/c.dominik/Tools/constants/constants.el

-- 
Aaron Ecay

Re: [O] [RFC] [PATCH] Warn about unexpanded macros on export

[Nicolas Goaziou]

Hello,

Jacob Gerlach  writes:

> While I expect that there's no code overlap with macro expansion, I asked
> about similar "stop on unresolved content" behavior with respect to links
> here: http://article.gmane.org/gmane.emacs.orgmode/90010/
>
> That discussion died off so I thought I'd bring up the topic again here.
>
> Would it be possible to cause export to stop (configurably, as discussed)
> when a link can't be resolved instead of just applying a special format
> (i.e. org-latex-link-with-unknown-path-format)

I have no objection to return an error when a fuzzy link, and id link or
a custom id link cannot be matched.

However, I do not like the idea of configurability as it would make the
code a bit more complex for little gain.


Regards,

-- 
Nicolas Goaziou

Re: [O] org-element-at-point fails in programming-modes

[Nicolas Goaziou]

Hello,

Thorsten Jolitz  writes:

> I noticed this issue again when calling `org-element-at-point` with
> point before the stars in 
>
> ,
> | ** [#A] whatsup :mytag:it:
> | hello world
> `
>
> in an emacs-lisp-mode buffer - it results in:
>
> ,
> | (paragraph (:begin 193 :end 246 :contents-begin 206 :contents-end 245
> | :post-blank 1 :post-affiliated 206 ...))
> `
>
> so it kind-of works outside org major-mode, but not correctly due to
> character-class problem in the regexp(s).

Again, `org-element-at-point' is not meant to be used outside of an Org
buffer. You can improve the situation by changing regexps, but you will
get bitten sooner or later.


Regards,

-- 
Nicolas Goaziou

Re: [O] Struggling with new exporter

[Nicolas Goaziou]

Hello,

phillip.l...@newcastle.ac.uk (Phillip Lord) writes:

> Okay, I've done it this way. Took a bit of fiddling since I need the
> project-alist to work in different configurations (i.e. interactively,
> in batch and in batch on a CI machine). Also, the timestamp stuff
> confused me -- org was skipping publication, even though the output file
> had been deleted.

You can force re-pulication.

> This part...
>
> #+BIND: org-latex-custom-lang-environments ((clojure "tawny"))
> #+BIND: org-latex-listings t
>
> isn't working at the moment. Source listings are coming out in verbatim.
> Can I set this in the project-alist. From looking at org-latex-src-block
> it would appear not.

On the development branch, you can add ":latex-listings t" property in
your project definition. In maint branch, you may dynamically bind
`org-latex-listings' around project publishing function call.


Regards,

-- 
Nicolas Goaziou

Re: [O] Call speed-commands with prefix-arg?

[Thorsten Jolitz]

Aaron Ecay  writes:

> Hi Thorsten,
>
> 2014ko irailak 23an, Thorsten Jolitz-ek idatzi zuen:
>> 
>> well, here is some positive feedback - thanks for tackling this!
>> I tried to port this to outshine.el right away, but can't make it to
>> work. But this might well be due to the fact that I'm on the console, no
>> X11. 
>> 
>> When I do C-u 4 t (with t for todo in the outshine speed cmds) I simply
>> get:
>> 
>> ,
>> | ;; ** DONE err
>> `
>> 
>> Since outshine-self-insert-command is a one-to-one copy of
>> org-self-insert-command, I guess if the patch works for you, it must be
>> a console problem that I have. Does your patch work for you on the
>> console too?
>
> It seems to, yes.  Can you test org mode (not outshine) in the console,
> and verify that the original patch works for you there?  If it doesn’t,
> that needs to be resolved before the patch can be merged.


I get 3 different results trying speed-command ':' with prefix:

 1. in Org, when edebugging 'org-set-tags-command', C-u : and C-u 4 :
 both result in speed-command " "

,
| Result: [32]
| 
| Result: 1 (#o1, #x1, ?\C-a)
| 
| Result: 0 (#o0, #x0, ?\C-@)
| 
| Result: 32 (#o40, #x20, ? )
| 
| Result: " "
| 
| Result: org-display-outline-path
`

 2. when not edebugging, C-u 4 : seems to work in both Org and Outshine

-> "All tags realigned to column 0"

 3. when doing C-u 4 t in outshine, with

,[ C-h f outshine-todo RET ]
| outshine-todo is an interactive Lisp function in `outshine.el'.
| 
| It is bound to M-# M-t.
| 
| (outshine-todo &optional ARG)
| 
| Call outorg to trigger `org-todo'.
`

,
| User-defined Speed commands
| ===
| t   outshine-todo
`

I get:

,
| ;; * ELISP SCRATCH
`

strange ...

-- 
cheers,
Thorsten

Re: [O] Call speed-commands with prefix-arg?

[Aaron Ecay]

Hi Thorsten,

2014ko irailak 23an, Thorsten Jolitz-ek idatzi zuen:
> 
> I get 3 different results trying speed-command ':' with prefix:
> 
>  1. in Org, when edebugging 'org-set-tags-command', C-u : and C-u 4 :
>  both result in speed-command " "

That’s because of the use of last-command-keys-vector, which will get
overwritten in edebug (the “ ” is the space that you used to step
through the function...)

> 
> ,
> | Result: [32]
> | 
> | Result: 1 (#o1, #x1, ?\C-a)
> | 
> | Result: 0 (#o0, #x0, ?\C-@)
> | 
> | Result: 32 (#o40, #x20, ? )
> | 
> | Result: " "
> | 
> | Result: org-display-outline-path
> `
> 
>  2. when not edebugging, C-u 4 : seems to work in both Org and Outshine
> 
> -> "All tags realigned to column 0"

Good.  :)

> 
>  3. when doing C-u 4 t in outshine, with
> 
> ,[ C-h f outshine-todo RET ]
> | outshine-todo is an interactive Lisp function in `outshine.el'.
> | 
> | It is bound to M-# M-t.
> | 
> | (outshine-todo &optional ARG)
> | 
> | Call outorg to trigger `org-todo'.
> `
> 
> ,
> | User-defined Speed commands
> | ===
> | t   outshine-todo
> `
> 
> I get:
> 
> ,
> | ;; * ELISP SCRATCH
> `
> 
> strange ...

Sounds like maybe the patch is not too well integrated into outshine.  I
get expected behavior under these conditions in org.

-- 
Aaron Ecay
PhD candidate, Linguistics
University of Pennsylvania

Re: [O] resizing windows from an org buffer, reqest for org-shiftcontrol-final-hook

[Brady Trainor]

Aaron Ecay  writes:

> Hi Bradley,
>
> 2014ko irailak 16an, Brady Trainor-ek idatzi zuen:
>> 
>> I have
>> 
>> (global-set-key (kbd "S-C-") 'shrink-window-horizontally)
>> (global-set-key (kbd "S-C-") 'enlarge-window-horizontally)
>> (global-set-key (kbd "S-C-") 'shrink-window)
>> (global-set-key (kbd "S-C-") 'enlarge-window)
>> 
>> in my init file, as suggested at 
>> http://www.emacswiki.org/emacs-en/WindowResize. However, when I am in an 
>> org file, the binding fails.
>> 
>> I had hoped that (setq org-support-shift-select t) would fix this, but 
>> it only seems to want to allow selection.
>> 
>> A solution might be similar to the one ...
>
> How’s your elisp?  Would you feel up to trying to create such a patch?

My elisp is not such that I can stop looking for work to tackle this.
(Negligible programming experience.) Though, I might certainly find
other excuses once I find gainful employment ;)


Brady

Re: [O] [patch, ox] #+INCLUDE resolves links

[Rasmus]

Hi,

Okay, I hope I got a better patch here.  I do — for sure — present
another dreadfully long email!  Let's start.

Nicolas Goaziou  writes:

>>> #+INCLUDE: file.org::#custom_id :noheadline :lines "3-"
>
> Is it `:only-contents' or `:no-headline'? Also ":kwd1 :kbd2 value" is
> usually a shortcut for ":kwd1 nil :kbd2 value" (at least in export
> attributes). Your example is thus confusing, you should include the
> expected value.
>
>   #+INCLUDE: "file.org::#custom_id" :only-contents t :lines "3-"

Well it's only-contents now.  Why?  It's more precise in terms of the
org-element terminology and it makes more sense when you include, say,
a table.

>> +elements.}.  If the keyword @code{:only-contents} is used, only the
>> contents
>> +of the element in included.  For headlines, drawers and properties
>   ^^
>
>> +assumed to be in Org mode format and will be processed normally.
>> File-links
>> +will be interpret as well:
>^

Sorry about that.  Fixed.

>>  ;;; ox.el --- Generic Export Engine for Org Mode
>> -
>>  ;; Copyright (C) 2012-2014 Free Software Foundation, Inc.
>
> You can remove this chunk.

As above.  [I should somehow disable whitespace cleanup when in source repos].

>> + (only-contents
>> +  (and (string-match
>> + ":\\(only-?contents?[[:space:]]*\\(?:'t\\|true\\|yes\\)?\\)"
>> value)
>
> This should be ":only-contents t" or ":only-contents nil".
> ":only-contents" alone can be tolerated as a shortcut for
> ":only-contents nil", but that's all.

Okay, I hope I got it now.  It's a rather forgiving regexp in terms of
mistakes.  Is that OK?


>> +   (prog1 t
>> + (setq value (replace-match "" nil nil value)
>
> Since `replace-match' cannot return nil here, you can remove

I did it in another way in the new patch now since to allow for nil
values.

>   (prog1 t ...)
>
> wrapper. If you insist on ONLY-CONTENTS being t, then

No, it's changed.

>> + (org-export--prepare-file-contents file location only-contents
>> lines
>
> Couldn't location, only-contents and lines be merged into a single
> argument? At the moment, you are either short-circuiting or breaking
> guard against circular inclusions (which relies on a combination of
> file-name and lines).

I try to do that now.  So the arguments of
`org-export--prepare-file-contents' are now unchanged compared to
master.

Note that lonely property drawers are now unconditionally discard if
they are in the beginning of the buffer — including just after an
initial drawer.

> IOW, each include keyword could be defined as a triplet of file name,
> beginning and ending global positions. You could implement a helper
> function to translate FILE LOCATION and ONLY-CONTENTS into this
> triplet,
> which would then be passed to `org-export--prepare-file-contents'.

I just pass a string of line numbers like before.

>> -(defun org-export--prepare-file-contents (file &optional lines ind minlevel 
>> id)
>> +(defun org-export--prepare-file-contents (file &optional location 
>> only-contents lines ind minlevel id)
>>"Prepare the contents of FILE for inclusion and return them as a string.
>>
>> +When optional argument LOCATION is a string the matching element
>> +identified using `org-link-search' is returned.  Note that
>> +`org-link-search-must-match-exact-headline' is locally set to
>> +non-nil.  When ONLY-CONTENTS is non-nil only the contents of the
>> +matched element in included.  If LOCATION is a headline and
>> +ONLY-CONTENTS is non-nil, drawers and property-drawers
>> +immediately following the first headline are also removed.
>> +
>>  When optional argument LINES is a string specifying a range of
>>  lines, include only those lines.
>>
>> @@ -3420,6 +3437,26 @@ This is useful to avoid conflicts when more than one 
>> Org file
>>  with footnotes is included in a document."
>>(with-temp-buffer
>>  (insert-file-contents file)
>> +(org-mode)
>
> You cannot enforce `org-mode' as the current major mode since you can
> include other file types.
>
>> +(when location
>> +  (condition-case err
>> + ;; enforce consistency in search.
>> + (let ((org-link-search-must-match-exact-headline t))
>> +(org-link-search location))
>> +;; helpful error messages
>> + (error (error (format "%s for %s::%s"
>> + (error-message-string err) file location
>> +  (narrow-to-region
>> +   (org-element-property
>> + (if only-contents :contents-begin :begin) (org-element-at-point))
>> + (org-element-property (if only-contents :contents-end :end)
>> (org-element-at-point)))
>> + ;; get rid of drawers and properties
>> +  (when only-contents
>> + (let ((element (org-element-at-point)))
>> + (while (member (org-element-type element) '(drawer
>> property-drawer))
>> + (delete-region (org-element-property :begin element)
>> + (org-element-property :end element))
>> + (setq element (org-element-at-point))
>
> This could be handled when building the triplet. Howe

Re: [O] [patchattached] Store link to url of eww

[Rasmus]

Aaron Ecay  writes:

> Hi Marco,
>
> Thanks for your patch.  TINYCHANGES can only be smaller than 15 lines,
> though, and your patch has more than that (even if we discount
> boilerplate like the license notice).  So you should probably do the
> copyright assignment which is described at
> .

I think he did:

Patch:
> From: Marco Wahl 

Worg:
> 14. Marco Wahl

Marco, you don't need to write TINYCHANGE if you have done the
paperwork.

—Rasmus

-- 
Dobbelt-A

Re: [O] [patchattached] Store link to url of eww

[Aaron Ecay]

Hi Rasmus,

2014ko irailak 23an, Rasmus-ek idatzi zuen:
> I think he did:
> 
> Patch:
>> From: Marco Wahl 
> 
> Worg:
>> 14. Marco Wahl

...that’s in the section for tinychange contributors without papers on
file though.

-- 
Aaron Ecay

[O] ob-R, about :results value verbatim drawer

[Feng Shu]

When I run follow code, it just work:

   #+begin_comment
   
   #+BEGIN_SRC R :results value verbatim drawer
   data <- list(a="[[./test1.org]]",b="[[./test2.org]]",c="[[./test3.org]]")
   c(data$a,data$b,data$c)
   #+END_SRC
   
   #+RESULTS:
   :RESULTS:
   [[./test1.org]]
   [[./test2.org]]
   [[./test3.org]]
   :END:
   


but when I add a #+PROPERTY, it show error like below, how to deal with
it ?  thanks ...

  #+PROPERTY: header-args:R :colnames yes :rownames no :exports both
  #+BEGIN_SRC R :results value verbatim drawer
  data <- list(a="[[./test1.org]]",b="[[./test2.org]]",c="[[./test3.org]]")
  c(data$a,data$b,data$c)
  #+END_SRC


  executing R code block...
  Wrote /tmp/babel-1984743i/ob-input-198472lB
  org-babel-R-evaluate-external-process: Wrong type argument: listp, "x
  [[./test1.org]]
  [[./test2.org]]
  [[./test3.org]]
  "

Re: [O] error exporting with reference to table in another file

[Aaron Ecay]

Hi John,

2014ko irailak 20an, John Kitchin-ek idatzi zuen:
> 
> Hi all,
> 
> I have this ina n org-file:
> 
> 
> #+NAME: anatase-tio2-elisp
> #+BEGIN_SRC emacs-lisp :var data=supporting-information.org:TiO2-data
> (remove-if-not (lambda (x) (string= "anatase" (nth 1 x))) data)
> #+END_SRC
> 
> #+RESULTS: anatase-tio2-elisp
> | TiO$_2$ | anatase | LDA| -2802.73 | 33.62 |  187.4 |
> | TiO$_2$ | anatase | AM05   | -2741.12 | 34.33 | 178.26 |
> | TiO$_2$ | anatase | PBEsol | -2763.61 | 34.25 | 178.71 |
> | TiO$_2$ | anatase | PBE| -2781.16 | 35.13 | 171.42 |
> 
> The code works fine, but when I try to export to a pdf or html I get errors
> like:
> 
> org-babel-exp processing... [2 times]
> org-babel-ref-resolve: Reference 'TiO2-data' not found in this buffer
> 
> Here is my org-version:
> 
> Org-mode version 8.2.7c (8.2.7c-25-g1faeb4-elpa @
> /Users/jkitchin/Dropbox/kitchingroup/jmax/elpa/org-20140811/)

FWIW I cannot reproduce this in emacs -Q, even with the same commit checked
out.  I’m attaching to this message the test files I used, in case anyone
else wants to try.  I did (setq org-confirm-babel-evaluate nil) before
doing the export.
#+NAME: anatase-tio2-elisp
#+BEGIN_SRC emacs-lisp :var data=supporting-information.org:TiO2-data :exports both
data
#+END_SRC

#+RESULTS: anatase-tio2-elisp
| TiO$_2$ | anatase | LDA| -2802.73 | 33.62 |  187.4 |
| TiO$_2$ | anatase | AM05   | -2741.12 | 34.33 | 178.26 |
| TiO$_2$ | anatase | PBEsol | -2763.61 | 34.25 | 178.71 |
| TiO$_2$ | anatase | PBE| -2781.16 | 35.13 | 171.42 |
#+name: TiO2-data
| TiO$_2$ | anatase | LDA| -2802.73 | 33.62 |  187.4 |
| TiO$_2$ | anatase | AM05   | -2741.12 | 34.33 | 178.26 |
| TiO$_2$ | anatase | PBEsol | -2763.61 | 34.25 | 178.71 |
| TiO$_2$ | anatase | PBE| -2781.16 | 35.13 | 171.42 |
-- 
Aaron Ecay

Re: [O] ob-R, about :results value verbatim drawer

[Aaron Ecay]

Hi Feng,

2014ko irailak 23an, Feng Shu-ek idatzi zuen:
> but when I add a #+PROPERTY, it show error like below, how to deal with
> it ?  thanks ...
> 
>   #+PROPERTY: header-args:R :colnames yes :rownames no :exports both
>   #+BEGIN_SRC R :results value verbatim drawer
>   data <- 
> list(a="[[./test1.org]]",b="[[./test2.org]]",c="[[./test3.org]]")
>   c(data$a,data$b,data$c)
>   #+END_SRC
> 
> 
>   executing R code block...
>   Wrote /tmp/babel-1984743i/ob-input-198472lB
>   org-babel-R-evaluate-external-process: Wrong type argument: listp, "x
>   [[./test1.org]]
>   [[./test2.org]]
>   [[./test3.org]]
>   "

The simple answer is don’t add the #+property line.  In particular, the
:colnames yes setting doesn’t play well with your code block.  If you
must have the #+property line for other reasons, override the global
setting of :colnames yes with :colnames no on the source block.

-- 
Aaron Ecay

Re: [O] Keeping metadata/notes about files and directories

[Christoph Groth]

Darlan Cavalcante Moreira wrote:

> See the custom commands for the agenda in the manual. You can create a
> command to do a search in specific files.

Indeed!  That’s great, I didn’t know that this is possible.  The custom
agenda commands of type “search” also support more complex searches like
“-{author:.*burkov} semimetal”.  This solves my searching problem rather
well.

Does org mode support such advanced searches also in other places?  It
doesn’t seem to be possible for “sparse tree” views of a single file.

> Of course you would need to change this custom command definition if
> you add more files, but with the idea of using one file per year from
> the other thread that means updating the custom command only once an
> year.

This is no problem at all, it could be even automatized.

> I didn't test this so see how searching in all of these files scale
> when compared to searching in one big file, but I imagine it would be
> faster.

If speed ever becomes a problem, I’ll see what can be done about it.