Erik Hetzner writes:
>> Seems fine, but I wonder if it wouldn’t be better to check the exit code
>> of say an annex command and relies on its checking. E.g. on my system
>>
>> (zerop (shell-command "cd ~/annex/doc.annex/ && git annex info --fast"
>> nil)) => t
>> (zerop (shell-command "
>> I have to admit I am reluctant to add another option to org-mode. What do you
>> think about a y-or-n-p if the file needs fetching that will ask if the user
>> would like to get the file from git annex?
>
> I think a y-or-n-p prompt would be fine. It also has the advantage that
> it would make
Erik Hetzner writes:
> Kyle Meyer wrote:
>> s/if/when/
>
> I’m sorry, you said this before, but I’ve always used =if= except in the case
> where I’d otherwise need =progn=. Is the principle here that =when= should be
> used when there is no else block?
Yes, for an 'if' without an 'else', I'd p
On Mon, 25 Jan 2016 23:40:33 -0800,
Kyle Meyer wrote:
>
> Erik Hetzner writes:
>
> […]
> > * mk/targets.mk: Fix cleantest target to for deleting git annex repos.
> ^^
> Typo
Thank you!
> […]
>
> s/if/when/
Erik Hetzner writes:
> * org-attach.el (org-attach-use-annex): New function to check if git
> annex should be used.
> (org-attach-annex-get-maybe): New function to get a file from git
> annex if necessary.
> (org-annex-open): Automatically fetch attached files from git annex when
> open
Hi Rasmus,
Thanks for the thoughtful feedback.
On Mon, 25 Jan 2016 13:19:56 -0800,
Rasmus wrote:
>
> Hi Erik,
>
> Thanks for the patch.
>
> Note that between git-annex v6 and annex.largefiles most of the checking
> is unnecessary. In my opinion it would be much more useful to start
> ripping ou
Hi Erik,
Thanks for the patch.
Note that between git-annex v6 and annex.largefiles most of the checking
is unnecessary. In my opinion it would be much more useful to start
ripping out annex specific code, though the automatic fetching should be
added.
Erik Hetzner writes:
> +(defun org-attach
* org-attach.el (org-attach-use-annex): New function to check if git
annex should be used.
(org-attach-annex-fetch-maybe): New function to fetch a file from git
annex if necessary.
(org-annex-open): Automatically fetch attached files from git annex when
opening if necessary.
* testing/lis
Hi Erik,
Erik Hetzner writes:
> If a user prefers to use git annex assistant or preferred content that
> shouldn’t
> interfere with this. But to my mind, opening an attachment is a pretty clear
> indication of the user’s desire to fetch the file from git annex, so it would
> be
> nice to do it
Rasmus writes:
> I want to know if e.g. the git annex (assistant?) could support
> transparently getting files. That is once I try to open file X, which is
> annexed and stored somewhere else, X will automatically be fetched
> /without/ the need to call "git annex get" first.
No, I don't think
Hi Rasmus,
On Tue, 05 Jan 2016 01:56:39 -0800,
Rasmus wrote:
>
> Hi Erik,
>
>
> For long prose like this I'd just export the patch (git format-patch)
> and attach it to an email like this. But this is also fine... Perhaps
> Kyle's method is more pro.
Thanks! I’m not sure which seems better
Thanks for the feedback, Kyle! I will make these changes and resubmit.
And thanks for the pointer to =git annex find PATH=. I think I can use that to
check if a file needs to be fetched.
(more below)
On Mon, 04 Jan 2016 22:21:41 -0800,
Kyle Meyer wrote:
>
> Thanks for the patch.
>
> […]
>
> >
Kyle Meyer writes:
> Rasmus writes:
>
Has Joey spoken for or against automatic fetching of content when
requested?
>>>
>>> I think I'm missing something. Why would he have an issue with running
>>> "git annex get"?
>>
>> I don't have anything against it, but in OP he also talks about
Rasmus writes:
>>> Has Joey spoken for or against automatic fetching of content when
>>> requested?
>>
>> I think I'm missing something. Why would he have an issue with running
>> "git annex get"?
>
> I don't have anything against it, but in OP he also talks about
> implementing something simila
Hi Kyle,
Kyle Meyer writes:
> Rasmus writes:
>
> [...]
>
>>> This patch automatically calls =git annex get PATH= when you open the
>>> attachment from Org, if the file has not been fetched already.
>>
>> This is a good idea. Though really this sounds like something that
>> should be done by th
Rasmus writes:
[...]
>> This patch automatically calls =git annex get PATH= when you open the
>> attachment from Org, if the file has not been fetched already.
>
> This is a good idea. Though really this sounds like something that
> should be done by the git annex assistant rather than per appl
Hi Erik,
> I couldn’t figure out how to add a comment to my patch, so here is a
little more
> commentary.
For long prose like this I'd just export the patch (git format-patch)
and attach it to an email like this. But this is also fine... Perhaps
Kyle's method is more pro.
> Right now, if you
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
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-ro
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 h
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!
21 matches
Mail list logo
