Generating the filename from name and file-ext for blocks with side-effects

Generating the filename from name and file-ext for blocks with side-effects

[Aitenate]

With ~:results file~, the absence of ~:file~ will cause the filename to
be constructed from the block name and ~:file-ext~, if they are both
present. To achieve that with ~:results file link~, I could only come up
with

~:var outFile=(alist-get :file (nth 2 (org-babel-get-src-block-info
't)))~

Have I missed something obvious? Is there a better way to do this?

If there isn't, would it be acceptable to add something like
`org-babel-get-src-block-param-value' or maybe more specific like
`org-babel-get-src-block-results-file-name'?

Regards,
Aitenate

Re: Generating the filename from name and file-ext for blocks with side-effects

[Ihor Radchenko]

Aitenate <aitenate@outlook.com> writes:

> With ~:results file~, the absence of ~:file~ will cause the filename to
> be constructed from the block name and ~:file-ext~, if they are both
> present. To achieve that with ~:results file link~, I could only come up
> with
>
> ~:var outFile=(alist-get :file (nth 2 (org-babel-get-src-block-info
> 't)))~

Seems right, but I do not understand why you would need such thing.

-- 
Ihor Radchenko // yantar92,
Org mode maintainer,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: Generating the filename from name and file-ext for blocks with side-effects

[Aitenate]

On 25/12/2024 15:30, Ihor Radchenko wrote:
> Aitenate <aitenate@outlook.com> writes:
> 
>> With ~:results file~, the absence of ~:file~ will cause the filename to
>> be constructed from the block name and ~:file-ext~, if they are both
>> present. To achieve that with ~:results file link~, I could only come up
>> with
>>
>> ~:var outFile=(alist-get :file (nth 2 (org-babel-get-src-block-info
>> 't)))~
> 
> Seems right, but I do not understand why you would need such thing.
> 

The aim is to not need to define a filename for each image, to minimise 
the boilerplate. Org has a mechanism for this, but it only works when 
Org creates the file.

Using a combination of noweb and file header arguments, with a property 
drawer, I was able to have each code block only require a unique name 
and the image code. That is except, because the image library creates 
the file, I need to specify a var to give a filename. Hence, I poked 
around until I found a way to use the computed filename.

While I'm happy with the solution I found, as a novice Org user, it 
seemed like I needed to reach into undocumented internals to do this. So 
I queried this, partly to understand if there was a better way, and 
partly to see if it was worth providing a better way or at least 
documenting a method.

Based on your response, maybe I'm doing something unusual. In which 
case, it's not surprising I couldn't find a more obvious way.

Re: Generating the filename from name and file-ext for blocks with side-effects

[Rudolf Adamkovič]

Ihor Radchenko <yantar92@posteo.net> writes:

> Seems right, but I do not understand why you would need such thing.

Aitenate <aitenate@outlook.com> writes:

> The aim is to not need to define a filename for each image, to minimise 
> the boilerplate.

+1 This should be built into Org and enabled by default.

I currently generate image names with a custom snippet, but it gets
trying and should not be necessary in the first place.

Instead, Org should generate a unique file name automatically, similar
to how tangle ':comments' work, and use that as the default value for
the ':file` argument, getting rid of the dreaded error message

  org-babel-execute:LANG: You need to specify a :file parameter

Rudy
-- 
"I would prefer an intelligent hell to a stupid paradise."
--- Blaise Pascal

Rudolf Adamkovič <rudolf@adamkovic.org> [he/him]
http://adamkovic.org

Re: Generating the filename from name and file-ext for blocks with side-effects

[Ihor Radchenko]

Aitenate <aitenate@outlook.com> writes:

>>> ~:var outFile=(alist-get :file (nth 2 (org-babel-get-src-block-info
>>> 't)))~
>> 
>> Seems right, but I do not understand why you would need such thing.
>> 
> The aim is to not need to define a filename for each image, to minimise 
> the boilerplate. Org has a mechanism for this, but it only works when 
> Org creates the file.
>
> Using a combination of noweb and file header arguments, with a property 
> drawer, I was able to have each code block only require a unique name 
> and the image code. That is except, because the image library creates 
> the file, I need to specify a var to give a filename. Hence, I poked 
> around until I found a way to use the computed filename.

Thanks for the explanation!
I do see how this can be useful.

> Based on your response, maybe I'm doing something unusual. In which 
> case, it's not surprising I couldn't find a more obvious way.

AFAIK, most people just specify the file names manually.
I suspect that it is mostly because the part of Org manual explaining
this is not easy to understand.

-- 
Ihor Radchenko // yantar92,
Org mode maintainer,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: Generating the filename from name and file-ext for blocks with side-effects

[Ihor Radchenko]

Rudolf Adamkovič <rudolf@adamkovic.org> writes:

>> The aim is to not need to define a filename for each image, to minimise 
>> the boilerplate.
>
> +1 This should be built into Org and enabled by default.
>
> I currently generate image names with a custom snippet, but it gets
> trying and should not be necessary in the first place.

Do you want to create a patch providing this functionality?

> Instead, Org should generate a unique file name automatically, similar
> to how tangle ':comments' work, and use that as the default value for
> the ':file` argument, getting rid of the dreaded error message
>
>   org-babel-execute:LANG: You need to specify a :file parameter

Do you want to extend `org-babel-generate-file-param' to return
something even when src block is not named and :file-ext is not given?
But how will you know the desired extension?

-- 
Ihor Radchenko // yantar92,
Org mode maintainer,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: Generating the filename from name and file-ext for blocks with side-effects

[Rudolf Adamkovič]

Ihor Radchenko <yantar92@posteo.net> writes:

> [...] and :file-ext is not given?  But how will you know the desired
> extension?

Oh, I missed that.  My local hack assumes `.svg', but that is not enough
for the general use case.

Perhaps, we could save as `$BASENAME.out', detect the image format, and
then rename to `$BASENAME.svg', for example.  If the file is not an
image, we leave it as `.out'.

We can detect the image type with `image-type':

  (image-type "...-59b9176e65c9.svg") => svg

If the above is sufficient, the problem reduces to:

  how to compute the `$BASENAME'?

[`org-babel-tangle-comment-format-beg' does something similar.]

Rudy
-- 
"One can begin to reason only when a clear picture has been formed in
the imagination."
--- Walter Warwick Sawyer, Mathematician's Delight, 1943

Rudolf Adamkovič <rudolf@adamkovic.org> [he/him]
http://adamkovic.org

Re: Generating the filename from name and file-ext for blocks with side-effects

[Ihor Radchenko]

Rudolf Adamkovič <rudolf@adamkovic.org> writes:

>> [...] and :file-ext is not given?  But how will you know the desired
>> extension?
>
> Oh, I missed that.  My local hack assumes `.svg', but that is not enough
> for the general use case.
>
> Perhaps, we could save as `$BASENAME.out', detect the image format, and
> then rename to `$BASENAME.svg', for example.  If the file is not an
> image, we leave it as `.out'.
>
> We can detect the image type with `image-type':
>
>   (image-type "...-59b9176e65c9.svg") => svg

Why do you think that the output file is always an image? It may not
be. It can be anything.

-- 
Ihor Radchenko // yantar92,
Org mode maintainer,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>