Re: [O] Bug: Asychronous export fails [8.3.2 (8.3.2-52-g6d0af5-elpa @ /home/rrt/.emacs.d/elpa/org-20151228/)]

[Reuben Thomas]

Hi,

I don't get an Emacs error in my Emacs, just "Process `org-export-process'
exited abnormally"; the error is in the child Emacs process. How do I get a
backtrace from that? (I checked the Org Manual, but it doesn't seem to
cover this case.)

On 3 January 2016 at 19:53, Nicolas Goaziou  wrote:

> Hello,
>
> Reuben Thomas  writes:
>
> > 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.
> > 
> >
> > With either 8.2.10 (as shipped with Emacs 24.4/5) or 20151228 (as
> > installed from ELPA), asychronous export to PDF via LaTeX fails unless I
> > have
> >
> > (setq org-export-async-debug nil)
> >
> > in my .emacs.
>
> Could you provide a backtrace of the error you're encountering? Also, if
> `org-export-async-debug' is non-nil, Org should leave an informative
> buffer somewhere with any error encountered on the other process.
>
> Regards,
>
> --
> Nicolas Goaziou
>



-- 
http://rrt.sc3d.org

[O] Expire deadline of none TODO items

[Florian Lindner]

Hello,

some of my nodes have a deadline but a TODO. Therefore they can't be
DONE. Yet, in the org-agenda they are displayed indefinitly until I set
a DONE for them, which I do not want (because they weren't a TODO in
the first place).

Can I make org-mode auto expire items that have a deadline but not a
TODO item? So that they are now shown in the agenda, when the deadline
have passed for e.g. 5 days.

Thanks,
Florian

Re: [O] [PATCH] ox-koma-letter.el: Add support for section

[Daniele Pizzolli]

On Sat, Jan 02 2016, Rasmus  wrote:

> Hi Daniele,
>
> First, thanks for your patch.
>
> Daniele Pizzolli  writes:
>
>> I was really surprised that headlines, that are so common in org-mode
>> are discarded by default in ox-koma-letter.
>
> Why?  They are not supported by scrlttr2.cls, except if you download an
> extra lco file, not distributed via CTAN.  As such, I don’t think it
> should be supported by ox-koma-letter.el.

Hello Rasmus,

thanks for you comment.  I try to explain my point of view better.  Now
the export to letter silently discard the headings text in the exported
tex.  This is quite bad, even if documented.  As a user I want to change
quite easily the export backend (text, latex, beamer, ...)  while
retaining most of my work.  Every backend as it's own supported
features, but discarding the input provided by the user does not provide
the best user experience to me.

By the way this patch does not change the final output, if there is no
section.lco available.  So there should be no regression and only
improvements.

I really prefer something that instead of discarding the user input
rewrite it to fit the backend features (if there is no heading/section
support, use something like the start of paragraph, and support section
only if enabled by the user) but this is beyond my coding abilities in
elisp, so I sent the minimal working patch with the minimal impact on
existing behaviour.

> A general headline property that allows to insert arbitrary code right
> before a headline (such as "@@latex:\clearpage@@") might be a more
> fruitful approach.

I guess this is another story.

>> +Add [sections] to LATEX_CLASS_OPTIONS with:
>> +
>> +#+LATEX_CLASS_OPTIONS: [sections]
>> +
>> +If section.lco is unavaliable the section are exported in the tex
>> +source but not rendered in the final pdf.
>
> Whether section.lco is available or not is a complicated question.  You
> first need to figure out what is the tex distribution (what if it’s not in
> PATH) and whether section.lco is available via something like kpsewhich.
> Note that e.g. TL also looks in the current path.

I use org to touch as less latex as possible, I just downloaded the
section.lco and put in the same directory of my org file and everything
was working.  A little before I used apt-file search section.lco but
since nothing was found I quickly reverted to the manual download.  I
wish that everything is packaged as distro package, but I can survive
some manual work.

Best,
Daniele

Re: [O] [PATCH] Fix typo

[Daniele Pizzolli]

On Sun, Jan 03 2016, Nicolas Goaziou wrote:

> Hello,
>
> Daniele Pizzolli  writes:
>
>> Fix a typo.
>
> Applied. Thank you.

Hello Nicolas,

Thanks to you for this and for all your effort in improving org-mode!

> BTW, have you signed the FSF papers? I thought you already had provided
> some patches, but I was apparently wrong.

No, never signed the paper.  This is in contrib, so signing the FSF
should be not mandatory.  Yes, I sent some patches, most of them as
draft or suggestions, but none went merged unmodified, some went merged
with some rewriting.  Anyway I will not give up and at some point in the
future I hope to send something good enough!

Best,
Daniele

[O] Can weekly agenda show children nodes?

[Tomasz Piotrowski]

Hi,

I usually plan my activities for a single day without specifying time of
day it should be accomplished, e.g.,

* <2016-01-04 Mon>
** Item 1
** Item 2

In agenda, children nodes of

* <2016-01-04 Mon>

are not shown, i.e., only * <2016-01-04 Mon> is displayed and is empty.

Can I tweak agenda to show

** Item 1
** Item 2

automatically, even without time of day defined from them?

Thanks a lot,

Best,

Tomasz Piotrowski

-- 
Sent with my mu4e

Re: [O] org files and projects nested git repositories

[Alan Schmitt]

On 2016-01-01 07:33, Ken Mankoff  writes:

> On 2016-01-01 at 05:02, Alan Schmitt  wrote:
>> Hello Ken,
>>>
>>> On my system this is a git repository and a cron (or actually
>>> LaunchAgent since I'm on OS X) does a =git commit -a
>>> = every night.
>>
>> I'm very interested about this. Could you please share your LaunchAgent
>> configuration file?
>
> I miss the simpler days of cron, but when in Rome or on OS X...

This is most useful, thanks a lot!

Alan

-- 
OpenPGP Key ID : 040D0A3B4ED2E5C7
Athmospheric CO₂ (Updated December 28, 2015, Mauna Loa Obs.): 402.60 ppm


signature.asc
Description: PGP signature

[O] habits not working

[Tyler Smith]

Hi,

Habits don't seem to be working for me anymore, and I'm not sure why.

Steps to reproduce:

emacs -Q

load org mode with minimal config for habits:

;; test-org.el
(require 'package)
(setq package-load-list
  '((org-plus-contrib t)))
(package-initialize)

(setq org-agenda-files '("~/scratch/orghabits.org"))

(setq org-modules '(org-habit))

With one habit defined in ~/scratch/orghabits.org:

* Habits
** TODO Exercise
   SCHEDULED: <2016-01-04 Mon .+1d>
   :LOGBOOK:  
   - State "DONE"   from "TODO"   [2016-01-03 Sun 22:32]
   - State "DONE"   from "TODO"   [2016-01-02 Sat 17:07]
   - State "DONE"   from "TODO"   [2016-01-01 Fri 23:03]
   - State "DONE"   from "TODO"   [2015-12-31 Thu 16:24]
   - State "DONE"   from "TODO"   [2015-12-30 Wed 20:53]
   :END:  
   :PROPERTIES:
   :STYLE: habit
   :LAST_REPEAT: [2016-01-03 Sun 22:32]
   :END:  

My agenda looks like:

Week-agenda (W01):
Monday  4 January 2016 W01
  orghabits:  Scheduled:  TODO Exercise
Tuesday 5 January 2016
  orghabits:  Scheduled:  TODO Exercise
Wednesday   6 January 2016
  orghabits:  Scheduled:  TODO Exercise
Thursday7 January 2016
  orghabits:  Scheduled:  TODO Exercise
Friday  8 January 2016
  orghabits:  Scheduled:  TODO Exercise
Saturday9 January 2016
  orghabits:  Scheduled:  TODO Exercise
Sunday 10 January 2016
  orghabits:  Scheduled:  TODO Exercise

When I looked at this yesterday only the next habit was listed, and was
displayed along with its consistency graph, which is what I expect to
happen.

"Habit" is listed in the modeline, and pressing 'K' brings up a message
that habits have been turned off, but no other change. Pressing 'K'
repeatedly turns habits on and off, but the agenda itself doesn't
change. 

How did I break this?

Emacs version:
GNU Emacs 25.0.50.2 (x86_64-pc-linux-gnu, GTK+ Version 3.18.5) of
2015-12-24

Org mode version:
Org-mode version 8.3.2 (8.3.2-59-g3d4c46-elpaplus @
/home/tws/.emacs.d/elpa/org-plus-contrib-20160104/)

Best,

Tyler
-- 
plantarum.ca

Re: [O] habits not working

[Dave Marquardt]

Tyler Smith  writes:

> Habits don't seem to be working for me anymore, and I'm not sure why.

> How did I break this?
>
> Emacs version:
> GNU Emacs 25.0.50.2 (x86_64-pc-linux-gnu, GTK+ Version 3.18.5) of
> 2015-12-24
>
> Org mode version:
> Org-mode version 8.3.2 (8.3.2-59-g3d4c46-elpaplus @
> /home/tws/.emacs.d/elpa/org-plus-contrib-20160104/)

Did you happen to update org-mode recently? There was a change around
the 8.3 timeframe about where you could put properties. See
http://orgmode.org/Changes.html

-Dave

[O] disqus

[David Arroyo Menéndez]

Hi all,

Some tutorial about disqus using orgmode?

Regards!

Re: [O] Org list source block

[Jarmo Hurri]

Nicolas Goaziou  writes:

>> Once again I fail when I try to do something very _simple_ with Org.
>
> You're building programmatically your document. I don't believe it
> belongs to "very simple" tasks.

Coming from a LaTeX background, Org is a real miracle tool, but it is
difficult to figure out how to do some things that used to be so
simple. Like in LaTeX you have a single \newcommand (or
\newenvironment), and then you use it wherever you want to. And if you
need similar document structure in multiple places, that is how a
programmer always does it.

>> BTW, if there is a solution to this, I think future generations might
>> benefit if something about it were mentioned in the manual in section
>> 11.6 "Macro replacement".
>
> As you noticed already, you are not using a macro. Why would it be in
> macro replacement?

To help the confused reader. Because people like me (common or rare
case?) just think: ok, I am going to define a macro for this. Then we go
to the org document and look up macros. Then we start doing online
searches for macros with linebreaks. Then we find discussions on
stackoverflow that say: "No you should do it with babel." Then we try to
figure out how to do it with babel. Then we post here. And so on.

My two absolute favorite tools from recent years are Org and Asymptote,
but neither have very beginner-friendly documentation. Partially because
both systems are so complex.

Yeah, I know I shouldn't whine: I could write the sections myself. But
others can do it better... :-)

> I think something along the following lines should work.
>
>   #+NAME: mylist
>   #+BEGIN_SRC org :results raw :exports none
>   - [ ] foo 
>   - [ ] bar 
>   #+END_SRC
>
>   #+CALL: mylist() :results raw
>   #+RESULTS:
>   #+CALL: mylist() :results raw
>   #+RESULTS:

This worked after adding org to org-babel-do-load-languges. Thanks!

Jarmo

[O] [BUG] org clock history no longer loaded from org-clock-persist-file

[Matt Lundin]

With the shift to lexical-binding in org-clock.el (commit
35bc1c8853c5cfe37930e3540a944a328af5198b), the function org-load-clock
fails to load the stored data in org-clock-persist-file.

These are the relevant setting in my .emacs:

(setq org-clock-persist t)
(setq org-clock-persist-file "~/data/org-clock-save.el")
(org-clock-persistence-insinuate)

Expected result: After calling the agenda for the first time, the
variable org-clock-history is populated with data.

Actual result: org-clock-history remains nil.

As far as I can tell, the problem lies with the call to load-file (line
2986). Because of the lexical binding, the (setq stored-clock-history
) statement stored in the org-clock-persist-file is evaluated but
because of the lexical scoping it has no effect on the
stored-clock-history in org-clock-load.

Ironically, this also means that stored-clock-history is defined as an
irrelevant global variable even while it remains undefined within
org-load-clock as a local variable. (Before lexical binding, the
opposite was the case: the call to load-file bound stored-clock-history
locally, but not globally).

Best,
Matt

Re: [O] Org list source block

[Jarmo Hurri]

"Charles C. Berry"  writes:

> If so, you can get it with
>
> * Test list
> #+NAME: my-list
> #+BEGIN_SRC org :exports none :results value org
>  - [ ] foo
>  - [ ] bar
> #+END_SRC
>
> #+BEGIN_SRC org :noweb yes :results replace :wrap org :exports results
><>
> #+END_SRC

Thanks, that worked!

All the best,

Jarmo

Re: [O] Can weekly agenda show children nodes?

[Richard Lawrence]

Hi Tomasz,

Tomasz Piotrowski  writes:

> I usually plan my activities for a single day without specifying time of
> day it should be accomplished, e.g.,
>
> * <2016-01-04 Mon>
> ** Item 1
> ** Item 2
>
> In agenda, children nodes of
>
> * <2016-01-04 Mon>
>
> are not shown, i.e., only * <2016-01-04 Mon> is displayed and is empty.
>
> Can I tweak agenda to show
>
> ** Item 1
> ** Item 2

I am not sure whether it is possible to do exactly what you asked; maybe
someone else will know.  But I wanted to suggest an alternative: rather
than using the headline hierarchy to represent your schedule, use
timestamps within the individual activities, like:

** Item 1
   <2016-01-04>
** Item 2
   <2016-01-04>

This will cause them to appear in the agenda on that date, as you
wanted.  It also has the advantage that rescheduling the individual
activities for a different day is as easy as changing the timestamp --
you don't have to move the headline around in your file, and can just
let the agenda take care of assembling your schedule for the day.

You may also find the SCHEDULED and DEADLINE keywords helpful; see the
"Deadlines and scheduling" section of the manual.

Hope that helps!

Best,
Richard

Re: [O] habits not working

[Tyler Smith]

On Mon, Jan 4, 2016, at 09:59 AM, Dave Marquardt wrote:
> Tyler Smith  writes:
> 
> > Habits don't seem to be working for me anymore, and I'm not sure why.
> 
> > How did I break this?
> >
> > Emacs version:
> > GNU Emacs 25.0.50.2 (x86_64-pc-linux-gnu, GTK+ Version 3.18.5) of
> > 2015-12-24
> >
> > Org mode version:
> > Org-mode version 8.3.2 (8.3.2-59-g3d4c46-elpaplus @
> > /home/tws/.emacs.d/elpa/org-plus-contrib-20160104/)
> 
> Did you happen to update org-mode recently? There was a change around
> the 8.3 timeframe about where you could put properties. See
> http://orgmode.org/Changes.html
> 

That was it, thanks. Following the change, the format must be:

* TODO Headline
  SCHEDULED: 
  :PROPERTIES:
  :style: habit:
  ...
  :END:
  :LOGBOOK:
  ...

I got thrown off because I store my past 'completions' in a :LOGBOOK:
drawer which was placed before the :PROPERTIES: drawer, which used to be
ok.

Best,

Tyler

[O] Renaming of +NAME for code blocks to in HTML export, no longer user defined

[Adam Aviv]

Hi all,

I've been using org-mode for some time to manage a course website, and I
developed a hack for source blocking where if I use the +NAME tag for
source doe like so:

#+NAME: helloworld.cpp
#+BEGIN_SRC c++ -r
#include  (ref:include)

using namespace std; (ref:namespace)

// Hello World in C++
int main(int argc, char * argv[]){
  cout << "Hello World" << endl; (ref:speak)
}
#+END_SRC

Then I could retrieve the name tag in the HTML source via the id when
exported, like so:



I can then use the id tag and CSS to have it float next to the code like
this:

[image: Inline image 1]


However, since I updated org-mode recently to version 8.3.2, the +NAME
tagging is no longer user defined. Instead, it get's a generic, org defined
name, such as orgsrcblock1. This means my little hack no longer works and I
get something that looks like this in the HTML exporting:



I have two questions for the group:

1) Is there a way to overwrite the generic source block naming? Or turn off
this feature somewhere? I can't seem to figure that out for myself.

2) Is there another hack that someone can suggest? For example, is there a
way to have a user defined  tag around the src code that will get
exported?

Thanks!

adam



-- 
Adam J. Aviv, PhD
*Asst. Professor*
*Computer Science*
*U.S. Naval Academy*
*(410) 293- 6655*

Re: [O] Renaming of +NAME for code blocks to in HTML export, no longer user defined

[Nick Dokos]

Adam Aviv  writes:

> Hi all,
>
> I've been using org-mode for some time to manage a course website, and I 
> developed a hack for source
> blocking where if I use the +NAME tag for source doe like so:
>
> #+NAME: helloworld.cpp
> #+BEGIN_SRC c++ -r
> #include  (ref:include)
>
> using namespace std; (ref:namespace)
>
> // Hello World in C++
> int main(int argc, char * argv[]){
>   cout << "Hello World" << endl; (ref:speak)
> }
> #+END_SRC
>
> Then I could retrieve the name tag in the HTML source via the id when 
> exported, like so:
>
> 
>
> I can then use the id tag and CSS to have it float next to the code like this:
>
> Inline image 1   
>
> However, since I updated org-mode recently to version 8.3.2, the +NAME 
> tagging is no longer user
> defined. Instead, it get's a generic, org defined name, such as orgsrcblock1. 
> This means my little hack
> no longer works and I get something that looks like this in the HTML 
> exporting:
>
> 
>
> I have two questions for the group:
>
> 1) Is there a way to overwrite the generic source block naming? Or turn off 
> this feature somewhere? I
> can't seem to figure that out for myself. 
>
> 2) Is there another hack that someone can suggest? For example, is there a 
> way to have a user defined
>  tag around the src code that will get exported?
>

It may be a bug: the code (in org-html-src-block) looks like this

  (label (let ((lbl (and (org-element-property :name src-block)
 (org-export-get-reference src-block info
   (if lbl (format " id=\"%s\"" lbl) ""

and I'm wondering whether the "and" should be an "or".

--
Nick

Re: [O] [PATCH] ox-koma-letter.el: Add support for section

[Rasmus]

Hi Daniele,

Daniele Pizzolli  writes:

> thanks for you comment.  I try to explain my point of view better.  Now
> the export to letter silently discard the headings text in the exported
> tex.  This is quite bad, even if documented.  As a user I want to change
> quite easily the export backend (text, latex, beamer, ...)  while
> retaining most of my work.  Every backend as it's own supported
> features, but discarding the input provided by the user does not provide
> the best user experience to me.

That's a fair point.  Nonetheless,

> By the way this patch does not change the final output, if there is no
> section.lco available.  So there should be no regression and only
> improvements.

> I really prefer something that instead of discarding the user input
> rewrite it to fit the backend features (if there is no heading/section
> support, use something like the start of paragraph, and support section
> only if enabled by the user) but this is beyond my coding abilities in
> elisp, so I sent the minimal working patch with the minimal impact on
> existing behaviour.


Whether sections.lco is available is nontrivial.  As I remember the patch,
it also imposed level two headings to be sections.

If you really think this is the right approach, perhaps the "H:" option
could be used to set the special heading level...  We’d need this since
you can specify the opening with a heading.

>>> +Add [sections] to LATEX_CLASS_OPTIONS with:
>>> +
>>> +#+LATEX_CLASS_OPTIONS: [sections]
>>> +
>>> +If section.lco is unavaliable the section are exported in the tex
>>> +source but not rendered in the final pdf.
>>
>> Whether section.lco is available or not is a complicated question.  You
>> first need to figure out what is the tex distribution (what if it’s not in
>> PATH) and whether section.lco is available via something like kpsewhich.
>> Note that e.g. TL also looks in the current path.
>
> I use org to touch as less latex as possible, I just downloaded the
> section.lco and put in the same directory of my org file and everything
> was working.  A little before I used apt-file search section.lco but
> since nothing was found I quickly reverted to the manual download.  I
> wish that everything is packaged as distro package, but I can survive
> some manual work.

This is because sections.lco is not part of KOMA-Script (like titlepage¹).
E.g. on my system with TL:

 $ kpsewhich sections.lco
 /home/rasmus/.texmf/tex/latex/koma-script/sections.lco

kpsewhich/tex also looks in the current directory, which is why you can
just place it in the same folder.

Cheers,
Rasmus

Footnotes: 
¹   http://www.komascript.de/titlepage

-- 
Warning: Everything saved will be lost

Re: [O] disqus

[Grant Rettke]

What did you want to have happen in what context?
Sincerely,

Grant Rettke


On Mon, Jan 4, 2016 at 9:10 AM, David Arroyo Menéndez
 wrote:
>
> Hi all,
>
> Some tutorial about disqus using orgmode?
>
> Regards!
>
>

[O] disqus

[David Arroyo Menéndez]

Hello,

How can I use disqus with orgmode? Some experience?

Thanks!

[O] Bug: time duration in capture template broken

[Charles Millar]

Until recently given the following capture template

"* APPOINTMENT %?%^{BeginTimeDuration}T %^{Location} %^{Reason}"

When prompted for the BeginTimeDuration and entered 2/29 09:00+1:00,  etc

would result in

* APPOINTMENT <2016-02-29 Mon 09:00-10:00> Location Reason

it now results in

** APPOINTMENT <2016-02-29 Mon (system time when capture made)> Location 
Reason


If no duration is given, the date and time as entered into the template 
are correctly captured


* APPOINTMENT <2016-02-29 Mon 09:00> Location Reason

Same error if I use 13:00-14:00 or 13:00--14:00 for duration, the start 
and end time still results in the system time when I C-c C-c the capture.


LMDE2
GNU Emacs 24.4.1 (x86_64-pc-linux-gnu, GTK+ Version 3.14.5) of 
2015-03-07 on trouble, modified by Debian
Org-mode version 8.3.2 (release_8.3.2-457-g4a6d19 @ 
/usr/local/share/emacs/site-lisp/org-mode/lisp/)


Charlie Millar

[O] [PATCH] org-attach.el: Fetch attachments from git annex

[Erik Hetzner]

* org-attach.el (org-attach-use-annex): New function to check if git
  annex should be used.
  (org-annex-open): Automatically fetch attached files from git annex when
  opening if appropriate.
---
 lisp/org-attach.el | 41 +
 1 file changed, 25 insertions(+), 16 deletions(-)

diff --git a/lisp/org-attach.el b/lisp/org-attach.el
index b3cd7b7..b3fde48 100644
--- a/lisp/org-attach.el
+++ b/lisp/org-attach.el
@@ -270,6 +270,14 @@ the ATTACH_DIR property) their own attachment directory."
   (org-entry-put nil "ATTACH_DIR_INHERIT" "t")
   (message "Children will inherit attachment directory"))
 
+(defun org-attach-use-annex ()
+  "Return true if we should use git annex for attachments."
+  (let* ((dir (expand-file-name org-attach-directory))
+(git-dir (vc-git-root dir)))
+(and org-attach-git-annex-cutoff
+ (or (file-exists-p (expand-file-name "annex" git-dir))
+ (file-exists-p (expand-file-name ".git/annex" git-dir))
+
 (defun org-attach-commit ()
   "Commit changes to git if `org-attach-directory' is properly initialized.
 This checks for the existence of a \".git\" directory in that directory."
@@ -279,20 +287,16 @@ This checks for the existence of a \".git\" directory in 
that directory."
 (when (and git-dir (executable-find "git"))
   (with-temp-buffer
(cd dir)
-   (let ((have-annex
-  (and org-attach-git-annex-cutoff
-   (or (file-exists-p (expand-file-name "annex" git-dir))
-   (file-exists-p (expand-file-name ".git/annex" 
git-dir))
- (dolist (new-or-modified
-  (split-string
-   (shell-command-to-string
-"git ls-files -zmo --exclude-standard") "\0" t))
-   (if (and have-annex
-(>= (nth 7 (file-attributes new-or-modified))
-org-attach-git-annex-cutoff))
-   (call-process "git" nil nil nil "annex" "add" new-or-modified)
- (call-process "git" nil nil nil "add" new-or-modified))
-   (incf changes)))
+(dolist (new-or-modified
+ (split-string
+  (shell-command-to-string
+   "git ls-files -zmo --exclude-standard") "\0" t))
+  (if (and (org-attach-use-annex)
+   (>= (nth 7 (file-attributes new-or-modified))
+   org-attach-git-annex-cutoff))
+  (call-process "git" nil nil nil "annex" "add" new-or-modified)
+(call-process "git" nil nil nil "add" new-or-modified))
+   (incf changes))
(dolist (deleted
 (split-string
  (shell-command-to-string "git ls-files -z --deleted") "\0" t))
@@ -465,8 +469,13 @@ If IN-EMACS is non-nil, force opening in Emacs."
 (file (if (= (length files) 1)
   (car files)
 (org-icompleting-read "Open attachment: "
-  (mapcar 'list files) nil t
-(org-open-file (expand-file-name file attach-dir) in-emacs)))
+  (mapcar 'list files) nil t)))
+ (path (expand-file-name file attach-dir)))
+(if (and (file-symlink-p path)
+ (org-attach-use-annex)
+ (not (file-exists-p (file-symlink-p path
+(call-process "git" nil nil nil "annex" "get" path))
+(org-open-file path in-emacs)))
 
 (defun org-attach-open-in-emacs ()
   "Open attachment, force opening in Emacs.
-- 
2.5.0

Re: [O] [PATCH] org-attach.el: Fetch attachments from git annex

[Eric Abrahamsen]

Erik Hetzner  writes:

> * org-attach.el (org-attach-use-annex): New function to check if git
>   annex should be used.
>   (org-annex-open): Automatically fetch attached files from git annex when
>   opening if appropriate.

WANT!

Re: [O] [PATCH] org-attach.el: Fetch attachments from git annex

[Erik Hetzner]

On Mon, 04 Jan 2016 21:09:55 -0800,
Erik Hetzner  wrote:
>
> * org-attach.el (org-attach-use-annex): New function to check if git
>   annex should be used.
>   (org-annex-open): Automatically fetch attached files from git annex when
>   opening if appropriate.

[…]

Hi all,

I couldn’t figure out how to add a comment to my patch, so here is a little more
commentary.

Right now, if you use git to sync your Org files and git annex to manage your
(large) attachments, and are on a different computer from the one you were using
when you added the attachment, you will typically have a dangling symlink to
your attachment until you call =get annex get PATH=. (This is how git annex is
intended to work.)

This patch automatically calls =git annex get PATH= when you open the attachment
from Org, if the file has not been fetched already.

(It would be nice to have Org do the same thing when exporting to HTML as well,
if the git annex file is an image that is being exported as an embedded image
link, but I can’t figure out how to do that.)

I have signed copyright assignment papers with the FSF.

best, Erik
--
Sent from my free software system .

Re: [O] [PATCH] org-attach.el: Fetch attachments from git annex

[Kyle Meyer]

Thanks for the patch.

Erik Hetzner  writes:

> +(defun org-attach-use-annex ()
> +  "Return true if we should use git annex for attachments."

s/true/non-nil/

> +  (let* ((dir (expand-file-name org-attach-directory))
> +  (git-dir (vc-git-root dir)))

I'd prefer

(let ((git-dir (vc-git-root (expand-file-name org-attach-directory ...)

[...]

> +(if (and (file-symlink-p path)

s/if/when/

> + (org-attach-use-annex)
> + (not (file-exists-p (file-symlink-p path
> +(call-process "git" nil nil nil "annex" "get" path))

- Should this display a message before calling "git annex get" to let the
  user know what's happening in case fetching the file takes some time?

- Should there be a setting the controls whether attachments are
  automatically fetched?

--
Kyle

Re: [O] [PATCH] org-attach.el: Fetch attachments from git annex

[Kyle Meyer]

Erik Hetzner  writes:

> I couldn’t figure out how to add a comment to my patch, so here is a little 
> more
> commentary.

Extra text can be placed after the three dashes and before the diff.

-- 
Kyle

Re: [O] Can weekly agenda show children nodes?

[Tomasz Piotrowski]

Hi Richard,

Thanks a lot! I think I had a wrong approach to scheduling tasks in
agenda. The solution you proposed works just fine.

Best wishes,

Tomasz


Richard Lawrence writes:

> Hi Tomasz,
>
> Tomasz Piotrowski  writes:
>
>> I usually plan my activities for a single day without specifying time of
>> day it should be accomplished, e.g.,
>>
>> * <2016-01-04 Mon>
>> ** Item 1
>> ** Item 2
>>
>> In agenda, children nodes of
>>
>> * <2016-01-04 Mon>
>>
>> are not shown, i.e., only * <2016-01-04 Mon> is displayed and is empty.
>>
>> Can I tweak agenda to show
>>
>> ** Item 1
>> ** Item 2
>
> I am not sure whether it is possible to do exactly what you asked; maybe
> someone else will know.  But I wanted to suggest an alternative: rather
> than using the headline hierarchy to represent your schedule, use
> timestamps within the individual activities, like:
>
> ** Item 1
><2016-01-04>
> ** Item 2
><2016-01-04>
>
> This will cause them to appear in the agenda on that date, as you
> wanted.  It also has the advantage that rescheduling the individual
> activities for a different day is as easy as changing the timestamp --
> you don't have to move the headline around in your file, and can just
> let the agenda take care of assembling your schedule for the day.
>
> You may also find the SCHEDULED and DEADLINE keywords helpful; see the
> "Deadlines and scheduling" section of the manual.
>
> Hope that helps!
>
> Best,
> Richard

-- 
Sent with my mu4e

[O] org-agenda-filter-by-tag-refine defaults to exclude

[Viktor Rosenfeld]

Hi,

I noticed that org-agenda-filter-by-tag-refine started to exclude selected tags 
by default recently because the 'refine in the call to org-agenda-filter-by-tag 
is interpreted as an exclude flag. The attached patch fixes this.

However, it seems that the function is superfluous because 
org-agenda-filter-by-tag can filter on multiple tags as well if called multiple 
times (that used not to be the case earlier). So maybe it should be deprecated 
and removed?

Best,
Viktor

diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el
index d91b64d..21928de 100644
--- a/lisp/org-agenda.el
+++ b/lisp/org-agenda.el
@@ -7580,7 +7580,7 @@ to switch between filtering and excluding."
 (defun org-agenda-filter-by-tag-refine (arg &optional char)
   "Refine the current filter.  See `org-agenda-filter-by-tag'."
   (interactive "P")
-  (org-agenda-filter-by-tag arg char 'refine))
+  (org-agenda-filter-by-tag arg char))

 (defun org-agenda-filter-make-matcher (filter type &optional expand)
   "Create the form that tests a line for agenda filter.  Optional



signature.asc
Description: Message signed with OpenPGP using GPGMail