Awesome!
Thanks again for all the help. It's been a crash course in org internals
and the contribution process.
Well prepared for next time to go much smoother.
Cheers,
-ryan
On Tue, Jun 14, 2022 at 6:47 AM Ihor Radchenko wrote:
> Ryan Scott writes:
>
> > I put together a clean setup in
Ryan Scott writes:
> I put together a clean setup in docker for running the tests and believe
> I've gotten to the source of the problem.
> However I've thought that a few times now.
Would you be interested to share it? It might be helpful for other
people trying to develop on Windows.
> This
I put together a clean setup in docker for running the tests and believe
I've gotten to the source of the problem.
However I've thought that a few times now.
This version of the patch has all tests passing.
The problem was in org-results-to-file and the attach dir detection. It
both had problems
Strange. I'll figure out a better setup for running the tests and get to
the bottom of that.
Thanks for the help.
On Tue, Jun 14, 2022, 00:10 Ihor Radchenko wrote:
> Ryan Scott writes:
>
> > Ah sorry about that. I'm on a windows laptop and didn't have make, so was
> > testing interactively and
Ryan Scott writes:
> Ah sorry about that. I'm on a windows laptop and didn't have make, so was
> testing interactively and they were passing.
> I cleaned that up and remove the f-* usage and verified under Ubuntu (on
> WSL) that the new tests are passing. I was getting some failures with
>
Ah sorry about that. I'm on a windows laptop and didn't have make, so was
testing interactively and they were passing.
I cleaned that up and remove the f-* usage and verified under Ubuntu (on
WSL) that the new tests are passing. I was getting some failures with
unrelated tests, but also get those
Ryan Scott writes:
>> > + (if (or noninteractive (y-or-n-p (format "Create ID for
>> entry \"%s\"?"
One more thing I forgot.
Please, use `yes-or-no-p'. `y-or-n-p' is not a good idea - it is too
easy to accidently confirm by hitting space.
Best,
Ihor
Ryan Scott writes:
> Had no experience with the :DIR: property or writing unit tests for Org,
> but I think I've got both covered now.
> The ID creation prompting now only happens if there is no result from
> org-attach-dir, which should address the :DIR: case.
Thanks!
> Let me know if there's
Had no experience with the :DIR: property or writing unit tests for Org,
but I think I've got both covered now.
The ID creation prompting now only happens if there is no result from
org-attach-dir, which should address the :DIR: case.
Let me know if there's anything about those tests that I
Ryan Scott writes:
> I believe I have addressed your feedback, Ihor.
> Attached is the latest version of the patch.
>
>- Merged latest master
>- :post is now handled correctly (verified with example of :post usage
>in the example at
I believe I have addressed your feedback, Ihor.
Attached is the latest version of the patch.
- Merged latest master
- :post is now handled correctly (verified with example of :post usage
in the example at https://orgmode.org/manual/Results-of-Evaluation.html)
- Added "(with quotes)"
Great. Just making sure that this particular approach to this feature or
type of feature wasn't fundamentally flawed given the established behavior
of org.
Thanks.
On Thu, Apr 21, 2022 at 11:02 PM Ihor Radchenko wrote:
> Ryan Scott writes:
>
> > With all of the layers and assumptions/behaviors
Ryan Scott writes:
> With all of the layers and assumptions/behaviors inherent in the way src
> block parameters are handled, do you feel like this is an approach that can
> work, or should it be abandoned?
I am not sure if I understand your concern.
Your code is reusing the existing convention
Yeah I just recently updated my fourth and realized there were some
necessary conflicts to resolve with the latest.
I'll take a look at addressing these issues and submit an updated patch.
Surprised I missed a calling location and secretly hope that it was added
recently for the sake of my poor
Ryan Scott writes:
> Here's my latest patch.
> Uses special :dir value 'attach to use attachment directory as working dir.
> Now prompts to create IDs for nodes that are missing.
> Solved a handful of issues with my previous versions of this and I've been
> using it regularly for a bit now.
>
>
Here's my latest patch.
Uses special :dir value 'attach to use attachment directory as working dir.
Now prompts to create IDs for nodes that are missing.
Solved a handful of issues with my previous versions of this and I've been
using it regularly for a bit now.
I've added documentation and
Ryan Scott writes:
> I've been working through a few different approaches. What's shaping up is
> something more general, having a special value
> for directory parameters (i.e. 'attach) and auto-detection of link paths that
> are in the attachment directory.
> The latest iterations don't
I've been working through a few different approaches. What's shaping up is
something more general, having a special value for directory parameters
(i.e. 'attach) and auto-detection of link paths that are in the attachment
directory.
The latest iterations don't move any files around, so can't
Ihor Radchenko writes:
> Greg Minshall writes:
>
>> i can imagine wanting to have input files and
>> output files in separate directories. (for ease in "make clean", if for
>> no other conceptual reason.) (but, probably i don't understand.)
I agree with this thought. We should separate two
Would it be better then as a new option entirely that sets the default
directory to the attachment directory and results in attachment links for
any inserted paths that are under that?
The attachment link detection could possibly be default behavior for link
insertion, but i can imagine that
Ryan Scott writes:
>(default-directory
> -(or (and dir (file-name-as-directory dir)) default-directory))
> +(or (and dir (if (eq dir 'attach)
> +(org-attach-dir t)
> + (file-name-as-directory dir)))
> +
Hi Ryan,
I’ve just had a glance, but this looks much better to me than what was proposed
earlier . Hopefully we’ll be able to get some feedback on this from others,
and then see it merged .
All the best,
Timothy
Okay, Had some time to put into this. Much happier with this approach as it
doesn't require any file moving and generally leaves src blocks to their
own devices.
The short version is that specifying ":dir 'attach" for a block uses the
directory from (org-attach-dir) as its working directory and
Yeah your second example is what I'm thinking. It makes this all a fairly
concise extension of that existing mechanism and does away with the file
move after execution.
On Sun, Sep 5, 2021, 06:21 Ihor Radchenko wrote:
> Ryan Scott writes:
>
> > It might make sense to fix up inserted "file:"
Ryan Scott writes:
> It might make sense to fix up inserted "file:" links that are under the
> attachment directory to be "attachment:" style links by default anyway, no?
> Then just being able to set the working directory to the attachment
> directory easily would get the rest of the way there.
That's starting to sound pretty good.
It might make sense to fix up inserted "file:" links that are under the
attachment directory to be "attachment:" style links by default anyway, no?
Then just being able to set the working directory to the attachment
directory easily would get the rest of the
Greg Minshall writes:
> i can imagine wanting to have input files and
> output files in separate directories. (for ease in "make clean", if for
> no other conceptual reason.) (but, probably i don't understand.)
Makes sense. Currently, there is :dir header arg to set working
directory (aka
Ryan, et al.,
i'm not entirely following the discussion, as i don't use "attaching".
but, fwiw, if i did, i can imagine wanting to have input files and
output files in separate directories. (for ease in "make clean", if for
no other conceptual reason.) (but, probably i don't understand.)
28 matches
Mail list logo
